[poppler] glib/poppler-input-stream.cc glib/poppler-input-stream.h poppler/Annot.cc poppler/Array.cc poppler/Array.h poppler/ArthurOutputDev.cc poppler/ArthurOutputDev.h poppler/CairoFontEngine.cc poppler/CairoFontEngine.h poppler/CairoOutputDev.cc poppler/CairoOutputDev.h poppler/Catalog.cc poppler/Catalog.h poppler/Dict.cc poppler/Dict.h poppler/Gfx.cc poppler/Gfx.h poppler/GlobalParamsWin.cc poppler/Object.h poppler/OutputDev.h poppler/Page.cc poppler/Page.h poppler/Parser.cc poppler/PDFDoc.cc poppler/PDFDoc.h poppler/PreScanOutputDev.cc poppler/PreScanOutputDev.h poppler/PSOutputDev.cc poppler/PSOutputDev.h poppler/SplashOutputDev.cc poppler/SplashOutputDev.h poppler/Stream.cc poppler/Stream.h poppler/TextOutputDev.cc poppler/TextOutputDev.h poppler/XRef.cc poppler/XRef.h qt4/src test/gtk-test.cc utils/HtmlOutputDev.cc utils/HtmlOutputDev.h utils/ImageOutputDev.h

Thomas Freitag Thomas.Freitag at kabelmail.de
Sun Jan 20 04:00:20 PST 2013


Am 20.01.2013 12:38, schrieb Adam Reichold:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello again,
>
> Am 20.01.2013 12:23, schrieb Thomas Freitag:
>> Am 20.01.2013 10:46, schrieb Adam Reichold: Hello,
>>
>> I was just testing this, trying to understand the exact
>> implications for usage of Poppler's qt4 frontend. From looking at
>> it, I can have as many threads in Page::renderToImage as I like as
>> long as I don't change the render hints while doing so. (Leaving
>> overprint aside for the moment.)
>>
>> This seems to work fine, but when I search the document parallel to
>> that (even using different page objects and only one thread in
>> Page::search), I am getting all sorts of error messages (but no
>> crashes) about the file being malformed. From Thomas' comment on
>> the bug report, I would infer this is a known limitation? Or
>> should this work?
>>> Yes, Adam, this is a known limitation at the moment. I know,
>>> that the bug report with over 140 comments is bad to read, but
>>> somewhere in the middle we decided to make in a first step only
>>> the page rendering thread safe. As I left yesterday as a last
>>> comment to that bug, one of the next steps will be to make the
>>> qt library completely thread safe. This is hopefully just a
>>> small task, because most of tat I had done that already, so we'll
>>> have it probably in the very next future.
> Thanks for the fast answer! This fits to what I inferred from the
> discussion on the bug report.
>
> About overprint: Is the call to globalParams::setOverprintPreview in
> Page::renderToImage a threading problem?
No, not really: overprintPreview is just read by the threads used in 
Page::renderImage. So changing the flag during rendering wil cause 
probably unpredictable results but nothing else. But probably it would 
be clearer to don't do it there but in Document::setRenderHint.

Cheers,
Thomas
>
>> So my current working assumption is: there can any number of
>> rendering threads, but all rendering has stop before something
>> else is to be called.
>>> Don't spend too much work waiting on all rendering threads
>>> finished. I.e. in Page::search we hopefully just need to use the
>>> thread safe version of PDFDoc::displayPage in
>>> Page::prepareTextSearch, i.e.
>>> parentDoc->doc->displayPage( &td, index + 1, 72, 72, rotation,
>>> false, true, false, null, null, null, null, true);
>>> instead of
>>> parentDoc->doc->displayPage( &td, index + 1, 72, 72, rotation,
>>> false, true, false );
>>> Cheers, Thomas
> Actually, if it becomes more difficult than that, I think I could live
> with two types of methods in the qt4 frontend (those that are safe to
> call concurrently, and those which are not). I just switched to
> protecting the Document and its children by a QReadWriteLock instead
> of QMutex, i.e. locking for writing by default and for reading when
> calling only safe methods (currently just rendering). So it is almost
> no work to gradually allow more methods to be called in parallel.
> (Code is on qpdfview's Launchpad page if you are interested.)
>
> Thanks again for the large amount of work you put into this, Thomas!
>
> Best regards, Adam.
>
>> Best regards, Adam.
>>
>> Am 19.01.2013 17:53, schrieb Albert Astals Cid:
>>>>> El Dissabte, 19 de gener de 2013, a les 08:44:34, Albert
>>>>> Astals Cid va escriure:
>>>>>> New commits: commit
>>>>>> 8eb489c355d734a72e140ce7e32470d048362499 Author: Thomas
>>>>>> Freitag <Thomas.Freitag at alfa.de> Date:   Sat Jan 19
>>>>>> 17:43:08 2013 +0100
>>>>>>
>>>>>> Make rendering thread-safe
>>>>>>
>>>>>> Bug #50992
>>>>> This is quite a big of a change, we did lots of testing to
>>>>> make sure it did not break things, but more testing is more
>>>>> than welcome.
>>>>>
>>>>> Cheers, Albert
>>>>> _______________________________________________ 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)
>
> iQEcBAEBAgAGBQJQ+9cnAAoJEPSSjE3STU34mCoIAIbl0MjcHGC7B7DsrIAk2d6z
> nbZv5lGTMGfWZzUEX/T3MB8g4HjeUtsvuNECocxEF1fPrD8Lda+E+9/sSQeZYeJI
> 98H89OUJUfi5fO6FnLSk2ieygtKXiBzOmlBr7CTTtsGjaO7qcXPuFUrwJGoJ/aiM
> g40nnyIEKiy3aUpy2AoYIo/6GinAwgz/KvIXfIxZJDOvdO3Buw5N8vF4/kvZ+t9p
> D0tU9nwtEfVeiytKODgV0/hdkBiccnkudt0/Q7Q47FGsSgzHZIMtOnwMviY5j2eP
> jOH65Itu5GmtUnhL7FGrgUvXXWQFPFJvaJP9zwrPTxqmSPWDdQOSyfbbDHZBRlg=
> =KFom
> -----END PGP SIGNATURE-----
> _______________________________________________
> poppler mailing list
> poppler at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/poppler
>
> .
>




More information about the poppler mailing list