>> Honestly I don't udnerstand what you're asking for, no, we don't have any >> makeItFaster() function.
Probably because I was rambling. Let me try to be more concise on the biggest aspect: If I have control over the input document's images (color space and/or mono, format, compression), for a given resolution do you know if there are specific settings that might be faster, notably bypassing internal conversions, etc. Note again: most documents have one image per page and nothing else; where other items are on the page I still want it to work properly if slower. Thanks for any suggestions. Linwood -----Original Message----- From: Albert Astals Cid [mailto:[email protected]] On Behalf Of Albert Astals Cid Sent: Wednesday, November 9, 2016 2:20 PM To: [email protected] Cc: [email protected] Subject: Re: [poppler] QT5 on Pi Render Performance for specific case El dimarts, 8 de novembre de 2016, a les 15:46:14 CET, [email protected] va escriure: > I have been (and am) reading what I can find on performance generally, > but I have a specific case and wonder if people might have suggestions. > > I am writing an application to run on a Raspberry Pi 3, which renders PDF's. > These PDF's 99% of the time contain multiple pages each of which has > exactly one image. I create these, so I have some control over the > type of image (I say "some" as I use Photoshop's Multi-page > presentation automation and not completely sure what it does under the > covers). > > I realize I can pull images out separately, but I hesitate to do that > because 1% (+/-) of the time there may be other things - annotations, > or the source of the PDF may be elsewhere and I have no control. But > the vast majority have zero text or other artifacts other than the image. > > At present to render a page at about 1200x900 takes almost 2 seconds > on the Pi. That's somewhere between impressive given it is a Pi, and too > slow. > :) > > Almost all the time is in the render call, specifically: > > new QImage(popplerPage->renderToImage(desiredScale, desiredScale) I've > instrumented the QT program and very little is taken in putting up the > image on the screen or other manipulation there. > > My question is whether there are any sweet spots in the code you may > suggest? Yes, the most expensive part of rendering a PDF is rendering the PDF :) Honestly I don't udnerstand what you're asking for, no, we don't have any makeItFaster() function. If you want to analyze what is slow and propose patches that make things faster we will be very happy :) Cheers, Albert > Anything I can do to the input image (color depth, format, etc.) that > might speed the render, anything in settings in poppler? I've tried > Arthur and Splash and while the former is slightly faster it is not > quite as good. I am not using any rendering hints at present. As I > want to cache the image itself, Arthur's ability to render into a > painter does not seem to help much (or maybe I'm missing how to best use it). > > I've already adjusted the resolution of the scanned image to be as low > as I can and still get crisp images at the final maximum size > > The input image is indexed color (which is actually grey) as it comes > from my scanner. I could convert to a real grey scale, or to color. > I tried bitmap but it introduces some artifacts, though I may be able to > manage a > good pattern or setting. Maybe. Will it make much difference? Or > poppler going to do the same work regardless? > > I am using the distro library on Ubuntu Mate for Pi, with CPP wrapper. > > Any advice welcomed. I am doing experiments, but there are so many > variables, am hoping that people more knowledgeable of the code might > know more fertile ground than random combinations. > > On a mostly unrelated note -- any recommendations of a simple example > of using QT bindings with poppler to create and save annotations? > That's next on my agenda. > > Thanks, > > Linwood _______________________________________________ poppler mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/poppler
