[poppler] Multi-threading rendering on Raspberry Pi

[pqt at LEFerguson.com]

Thank you Thomas, for the quick response.  I was trying not to sound like it was a complaint, but rather looking for any ideas for an unusual case.  For example, you may have given me one: 

> All threads, in your case two, have to share the PDFDoc, Catalog, XRef-table and inputstream, 
> so yes, of course there are a lot of mutex locks, especially when a lot of objects are shared
> between the pages. 

I may be able to set up a test, and create multiple instances of the PDF doc itself.  These are not huge, and I think memory will not be a constraint, and I am not writing to the documents.  With completely separate document instances, I assume the rendering might proceed unimpeded in each thread.

My real goal is to get two pages displayed as fast as I can.  From that point on there's lots of "person think time" available to render in background.

> So I guess that in your case a lot of time is needed in parsing the PDF objects and not so 
>much in rendering them.

That's actually a bit of my bafflement as well. Mostly these are PDF documents that contain nothing at all except one image per page - no text, no annotations. I take X TIFF's in photoshop, and produce an X page PDF. So really it should be spending very little time parsing.

Which... maybe... is also worth looking at.  Maybe instead of rendering a page, I can just pull out the image element and treat it independently.  I'll dummy up a test run and see how much of the Pi's long rendering time is dealing with the image itself.

I used PDF (vs a bunch of page images) because I may also want, eventually, to use music sheets rendered as PDF's by notation software, where each note and staff becomes a separate element.  So just letting Poppler do all the work is very attractive rather than me looking under the covers. But it may be worth a quick trial run.

Thanks again for the response.  I was hunting for ideas to try, and you have given me some.

Linwood