-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05.08.2012 17:26, Albert Astals Cid wrote: > El Diumenge, 5 d'agost de 2012, a les 17:16:46, Adam Reichold va > escriure: On 05.08.2012 16:36, Ihar `Philips` Filipau wrote: >>>> On 8/5/12, Albert Astals Cid <[email protected]> wrote: >>>>>> Exactly, that's why I am unsure whether I can change >>>>>> >>>>>> QImage renderToImage(double xres=72.0, double yres=72.0, >>>>>> int x=-1, int y=-1, int w=-1, int h=-1, Rotation rotate = >>>>>> Rotate0) const; >>>>>> >>>>>> to >>>>>> >>>>>> QImage renderToImage(double xres=72.0, double yres=72.0, >>>>>> int x=-1, int y=-1, int w=-1, int h=-1, Rotation rotate = >>>>>> Rotate0, bool multiThreading = false) const; >>>>>> >>>>>> in "Poppler::Page" defined in "qt4/src/poppler-qt4.h" >>>>>> without breaking something. Recompiling is obviously >>>>>> fine, but would applications that were linked against >>>>>> Poppler before that change still work? >>>>> >>>>> No, they wouldn't. >>>>> >>>>> Here a nice overview of the dos and donts. >>>>> http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ >>>> >>>> >>>>> Extremely valuable link. Thanks. >>>> >>>> On topic. Quote from the link: -- If you need to add >>>> extend/modify the parameter list of an existing function, you >>>> need to add a new function instead with the new parameters. >>>> In that case, you may want to add a short note that the two >>>> functions shall be merged with a default argument in later >>>> versions of the library: >>>> >>>> void functionname( int a ); void functionname( int a, int b >>>> ); //BCI: merge with int b = 0 -- The open question is >>>> whether the "need" is there. > > For a simple document (some mathematical text), the average time > for the rendering alone goes from *(46 +- 10) ms* per-page (using > Poppler 0.20.2) to *(69 +- 20) ms* per-page (using Poppler master > with Thomas' patch) on my system. (Using 100 samples in both > cases.) > >> Well, 20 msec is something i can live with, i'm more scared on >> "big documents" if it adds something like one second or half a >> second :D Ok, I tested a very image-heavy document where the benefits of multi-threading a rather pronounced and the rendering time per-page went up from (945 +- 270) ms to (1131 +- 256) ms. But of course, the overall rendering time went down significantly as all three CPU cores where constantly maxed out using multi-threading whereas two were always idling without it. So in this case, the overhead decreased from 33% to 16%. But, the document is image-heavy, not complicated w.r.t to the structure. Also, I noticed that Poppler::Page::renderToPainter creates a ArthurOutputDev for each call as well and always creating a SplashOutputDev would have the added benefit of removing all output device handling from Poppler::Document and Poppler::DocumentData. (I.e. Poppler::DocumentData::getOutputDev could go the way of the Dodo and things like Poppler::Document::setPaperColor and ::setRenderHints would simplify.) > I changed Poppler::Page::renderToImage to just create a temporary > SplashOutputDev for every call and used the fMT flag, so the > overhead is probably mostly creating the output device. Not sure > whether caching the output device in PageData is good idea... (I > think it would be ideal to have as many output devices as rendering > threads but IMHO that would imply too close a coupling to the > application using the library.) > >> Yeah well, creating an SplashOutpuDev is not "cheap" since it >> creates the SplsahBitmap and Splash. > > Maybe you could tell what kind of data you'd like to see so that I > could try to provide it? Not sure how helpful such a simple average > is. > >> Well, as far as i can see the only overhead is the copying of the >> xref, what about a program that calls the xref copying function >> so I can call it over all the thousand pdf i have lying around to >> see how much time takes on them? I am not sure I am versed enough in the internal Poppler API to achieve this. Could you give me a hint where in the code base I could find a similar test? >> Albert > > >>>> Wrt, multithreading. Just a thought. I had impression that >>>> it should be already possible to create a private instance >>>> (per thread) of the document for the same PDF, so that the >>>> threads can rasterize the pages of the same PDF in parallel. >>>> Only trade off is the memory consumption. > > We previously did this in qpdfview but I don't like the idea of > reparsing the document over and over to render each page. It also > adds problems for password-protected documents and the semantics of > what happens when the file changes on-disk are different. > > Regards, Adam. > >>>> _______________________________________________ poppler >>>> mailing list [email protected] >>>> http://lists.freedesktop.org/mailman/listinfo/poppler > >> _______________________________________________ poppler mailing >> list [email protected] >> http://lists.freedesktop.org/mailman/listinfo/poppler > _______________________________________________ poppler mailing > list [email protected] > http://lists.freedesktop.org/mailman/listinfo/poppler > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQHpZlAAoJEPSSjE3STU34hqYH/A4aaOE9LvpZ1b1z8EGO0gDG 1EKiG1zMXe7Q5TKqvwwH1E5wF89csduN9rZC2gJLWGaN7VNEeVLnVdp8FM9STV1n MXKN2VNlyG4ef3+qEWjsSGOh+AF8bprwSNVSBMXRDH7EKuMZfD2YxIsw4xRhIeFL GJ1ALLpCXUTmA8r/BG2jaRVbAJlxIwa8iCgEqYu6A54OFI5ge6SAmek/dYE5WcSV 1cMxlvIgVMFZUsYs2sdTI+8KAFOjQeLBssGVowyx0Ww4JlMVQYLwaQ+bU3126VIJ 2x2dspOP8qH8srohGfBhp7Dljas3ckUr/9/dAA6XHKVtLyCU1NQXIJbih7TvLxI= =AKCf -----END PGP SIGNATURE----- _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
