[poppler] Question on how to ensure API compatibility

[Adam Reichold]

-----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 <aacid at kde.org> 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 poppler at lists.freedesktop.org 
>>>> http://lists.freedesktop.org/mailman/listinfo/poppler
> 
>> _______________________________________________ poppler mailing
>> list poppler at lists.freedesktop.org 
>> http://lists.freedesktop.org/mailman/listinfo/poppler
> _______________________________________________ poppler mailing
> list poppler at lists.freedesktop.org 
> 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-----