... 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