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 <[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 > 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? 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 > > -----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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/poppler _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
