Hi Linwood!
Am 22.02.2017 um 15:32 schrieb [email protected]:
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:
Oh, I didn't feel tackled :-D, and I even don't care about any
complaints. If it's too hard I just don't answer J
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.
But time reading: the file handle of the PDF document is also shared
between the threads of course, so only one thread can read at currently.
And every read costs a new positioning in this case. But still this is
just a guess.
Cheers,
Thomas
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
_______________________________________________
poppler mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/poppler