[poppler] Question on how to ensure API compatibility

[Thomas Freitag]

Am 05.08.2012 17:26, schrieb Albert Astals Cid:
> El Diumenge, 5 d'agost de 2012, a les 17:16:46, Adam Reichold va escriure:
>> -----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.)
> 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
>
>> 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?
Just call displayPageSlice with fMT = gTrue (small modification in 
pdftoppm, see my testcase) and You should see how much time it takes.

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