[poppler] Question on how to ensure API compatibility

[Adam Reichold]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



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

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

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.

> 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
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQHo5eAAoJEPSSjE3STU34DJQIALNb5z0kdyNzzAhHkGvwkyZK
IPX01BMfvGCIOy2TuplGI/njlDesVfA4j+tAazVY2xt6CPN64fPpz+t56JC+CoV/
XrIqD5b9kfzCqb83RUabK1s7OnDex497n/VdxoRrl9LAkrgJ4YFQXWq2+aj06TD4
l9j96ldys0bkqJnEjSzHAHFCwbFFbzDhISNHOKLCkYIkHJtw/oOnxdqMuX9WE/ek
HtRFecYwEteyUANygcvgtXrb2wH72/z1Rff7VnRGA/gFv0bF9h7Z4tqxKd8WJDxX
+TpHZ5+QwZVxa+OqM02drwjnQLp/3xij89NYMxMu4lGa+c07Z9P15scfrdttaNo=
=W2rq
-----END PGP SIGNATURE-----