[poppler] Question on how to ensure API compatibility

Tue Aug 7 13:50:16 PDT 2012

El Diumenge, 5 d'agost de 2012, a les 17:51:01, Adam Reichold va escriure:
> -----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 

renderToPainter creates 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?

Just to a sample program that does
foo = new PDFDoc()
foo->getXRef()->copy();

And check how much time it takes

Cheers,
  Albert

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