Rendering this document is slow

456 views
Skip to first unread message

jianpeng lin

unread,
Oct 30, 2023, 2:18:43 PM10/30/23
to pdfium
I used sample/pdfium_test to render the attached document, and the rendering time took 90+ seconds. skia is enabled。
11.pdf

jianpeng lin

unread,
Nov 3, 2023, 5:32:58 AM11/3/23
to pdfium
I found that the implementation of CPDF_RenderStatus::ProcessTransparency is somewhat inappropriate. It immediately rasterizes all objects with transparency and then compose them with the background image. When there are many such objects, the rendering speed will be very slow. Quoting PDF specification 11.2 Note1, The order in which objects are specified determines the stacking order but not necessarily the order in which the objects are actually painted onto the page. In particular, the transparency model does not require a PDF processor to rasterize objects immediately or to commit to a raster representation at any time before rendering the entire stack onto the page. This is important, since rasterization often causes significant loss of information and precision that is best avoided during intermediate stages of the transparency computation. 

jianpeng lin <linjian...@gmail.com> 于2023年10月31日周二 02:18写道:
I used sample/pdfium_test to render the attached document, and the rendering time took 90+ seconds. skia is enabled。

--
You received this message because you are subscribed to the Google Groups "pdfium" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pdfium+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pdfium/e5e7ecf8-8bf1-4f1a-906d-921c6b7dd806n%40googlegroups.com.

K. Moon

unread,
Nov 3, 2023, 1:17:26 PM11/3/23
to jianpeng lin, pdfium
It's better to file feedback like this on the bug tracker (https://crbug.com/pdfium/new). That said, there are a number of known issues in PDFium around performance in specific cases like this; feedback and additional data is always welcome, but there isn't necessarily going to be a quick fix.

The section in the PDF specification that you're quoting doesn't really have to do with performance, but precision. Implementations with more complex handling of transparency can reduce loss of precision by performing intermediate operations at higher precision, but rasterization to the final output device still has to occur eventually.

Lei Zhang

unread,
Nov 3, 2023, 1:25:45 PM11/3/23
to jianpeng lin, pdfium, K. Moon
Yes, it would be best to file a bug to track this issue. Profiling
shows that almost all the time is spent in
CFX_ScanlineCompositor::CompositeRgbBitmapLine().
> To view this discussion on the web visit https://groups.google.com/d/msgid/pdfium/CACwGi-4DKT6uCNU19vR5nrP2nJWG5_koaZeMnTjDKpDLsLXGVg%40mail.gmail.com.

jianpeng lin

unread,
Nov 6, 2023, 3:08:59 AM11/6/23
to Lei Zhang, pdfium, K. Moon
Thanks for your advice. 

Lei Zhang <the...@chromium.org> 于2023年11月4日周六 01:25写道:

Lei Zhang

unread,
Nov 6, 2023, 12:52:04 PM11/6/23
to jianpeng lin, pdfium, K. Moon
Thanks for filing crbug.com/pdfium/2093 for this issue.
Reply all
Reply to author
Forward
0 new messages