find . \( -name "*.cpp" -or -name "*.h" -or -name "*.c" -or -name "*.cc" \) -exec clang-format -i {} \;
If you reached this file doing a git blame, please see README.clang-format (added 2 commits in the future of this one)
The check whether to allocate a new QMutex was unprotected.
Two threads may check and allocate concurrently, but only one pointer gets
remembered, the other one will leak. In worst case the returned
mutex is different for two threads, so that two threads try to
synchronize by using two different mutexes.
Use jq to filter compile_commands.json to not include the compilation of
autogenerated files, we don't want to check those
Also filter out the synctex folder, since that is imported code
Summary:
Only supported by the pdf backend if using poppler >= 0.63
Sadly had to change the generator API
Text cancellation is a bit wobbly still since poppler has large parts
of the code where doesn't check for the cancellation flag, but that
is something that will get automagically fixed for us if the poppler
side is improved
Test Plan: Needs https://bugs.freedesktop.org/show_bug.cgi?id=104263
Reviewers: ervin, rkflx
Reviewed By: ervin, rkflx
Subscribers: #okular
Tags: #okular
Differential Revision: https://phabricator.kde.org/D9328
Summary:
This way pages that take more than 500ms to render get updated every so often so that the
user can see that the program didn't hang, it's just that it's taking long to render
Tags:
incremental rendering, partial updates
BUGS: 344081
Subscribers: #okular
Tags: #okular
Differential Revision: https://phabricator.kde.org/D8379
Summary:
so that pixmap generation gets a chance to start before the text generation
This makes that on files where both the text generation and the pixmap generation
are slow at least we see something "as fast as possible" since only either text generation
or pixmap generation threads run at the same time
Reviewers: #okular, mlaurent
Reviewed By: mlaurent
Subscribers: michaelweghorn, dvratil, mlaurent, #okular
Tags: #okular
Differential Revision: https://phabricator.kde.org/D8378
It's straighforward implementation. Every single place, where there were call for (or with) TilesManager, now has a DocumentObserver as companion. The m_tiledManager reference in PagePrivate was changed to QMap<DocumentObserver, TilesManager>.
REVIEW: 113986
Includes some fixes from Albert:
* kscreen cmake fixes
Don't make libkscreen mandatory, give the proper version we need
* Fix the @since
* Kill Resolution and use a QSizeF
I first thought QSizeF didn't make sense, but well what's a dpi if not a number of pixels in width and some others in height?
* Remove unwanted const
* Remove unneeded utils.h includes
* Fix comments on realDPIXY()
* Make it compile in non X11
REVIEW: 111829
Just use the pointer as id :-)
This is BIC and SIC, increase the soversion now to makes sure we don't forget in the future
Patch based in an earlier patch by Bogdan Cristea <cristeab@gmail.com>
REVIEW: 109115
The visible region was set in the PixmapRequest only a tiles manager was
available. Because of that the generator could check if it was supposed
to used tiles by simply checking if its normalized rect was null.
However is good to know the visible region even when a tiles manager is
not present. This way if the request is big enough to start a tiles
manager we already know the visible region and can change the
PixmapRequest accordingly.
... but, as it's proving to be buggy (text disappearing from menus) and crashing (out-of-range font engine list), it's disabled for now, define OKULAR_TEXTDOCUMENT_THREADED_RENDERING to try it.
svn path=/trunk/KDE/kdegraphics/okular/; revision=804719
This way we can tell to "merge" in a smart way the new pixmap request with the enqueued ones of the same ID.
Add a (private) slot to refresh all the pixmaps of a page.
svn path=/trunk/KDE/kdegraphics/okular/; revision=783259
This affects all the generators that use the internal generator threading, own threading models have to be fixed properly.
svn path=/trunk/KDE/kdegraphics/okular/; revision=723161
- make the Generator internally keep an pointer to the private class Document, so we can access easily to the Document' stuff
svn path=/trunk/KDE/kdegraphics/okular/; revision=712498
Instead of having a synchronous function that extracts all the information at once, use a function to read the fonts of a single page.
This way, we can get all the result step by step (aka page by page), and possibly in an asynchronous way.
The resuls of the font "scanning" are sent via signals, as well the end of the work.
So, instead of block waiting for the results of all the document at once, the Fonts tab in the properties dialog can have a progress bar with the progress, and the results (the fonts) that are added incrementally to the list.
Only two minor things are left:
- the process is always asynchronous at the moment, as the only generator that can provide this kind of information is the Poppler one (safe)
- there is no check for duplicate fonts
But they should be easy to solve.
svn path=/trunk/KDE/kdegraphics/okular/; revision=685002
