Images that are both hidden and filtered dramatically increase PDF rendering time |
||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.2 Safari/605.1.15 Steps to reproduce the problem: 1. Download attached test page and place any PNG image called bug.png next to it. 2. Open the test page in Chromium. 3. Press Cmd/Ctrl+P or open print dialog otherwise. What is the expected behavior? Document preview is visible in print dialog in a second or two. What went wrong? Document preview is shown after significant amount of time. You may want to add some additional <img> tags in the test page to see the rendering time getting even longer. Did this work before? Yes Broken by CL https://crrev.com/c//923572 (SlimmingPaintV175 reland) Chrome version: 72 Channel: dev OS Version: OS X 10.12.6 Flash Version:
,
Dec 31
,
Jan 1
Thanks for filing the issue! Able to reproduce the issue on chrome version 72.0.3626.28 and on the latest canary 73.0.3657.0 using Mac 10.14.1, Ubuntu 14.04 and Windows 10 Bisect Information: ------------------- Good Build: 68.0.3428.0 Bad Build: 68.0.3429.0 Suspecting the same from comment#1 https://chromium.googlesource.com/skia/+/825911444082ddd26e9f8bef349e44e048009f5d Review URL: https://skia-review.googlesource.com/127051 @Hal Canary: Please help in assigning it to the right owner if this isn't related to your change.
,
Jan 5
A few results of my research: - Images that are both hidden and filtered lead to PaintLayerPainter::PaintEmptyContentForFilters call which has a size of 0x0. - In ConversionContext::Convert, 0x0 size is ignored and SaveLayerOp gets default PaintOp::kUnsetRect rect. - In SkCanvas::internalSaveLayer, PaintOp::kUnsetRect turns into getDeviceClipRect() which is a page rect for SkPDFDevice (which is 2321x3024 pixels). - In SkPDFDevice::onCreateDevice, an SkBitmapDevice of that size is created because the layer has image filter. - Finally, in SkPDFDevice::drawDevice called from SkCanvas::restore after empty content, a page of 2321x3024 pixels is processed, which is obviously slow. Taking into account that this processing occurs for every image that is both hidden and filtered, the more images we have the slower PDF preview is. Hope this helps to fix the issue.
,
Jan 7
Based on comment#4 research, I've uploaded patch that fixes long print preview: https://chromium-review.googlesource.com/c/chromium/src/+/1396958. Hope this is the right fix.
,
Jan 7
Okay, sounds like a Chrome issue.
,
Jan 8
,
Jan 8
dbessonov has a patch in review at https://chromium-review.googlesource.com/c/chromium/src/+/1396958
,
Jan 11
This issue has been marked as started, but has no owner. Making available.
,
Jan 14
Setting pdr@ as owner because they are helping the change through the commit process. The real owner can be assigned once permissions come through.
,
Jan 14
Also reducing priority to P2, since it's taken 4 releases for anyone to report the issue.
,
Jan 15
Woohoo, dbessonov now has bug editing privileges and can be marked as working on the bug.
,
Jan 17
(5 days ago)
<div style="width: 6000px; height: 6000px;"></div> This alone makes Chrome 68+ print preview work forever while being instantaneous in pre-68 Chrome.
,
Jan 17
(5 days ago)
...and bisects identically to comment 1. |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by woxxom@gmail.com
, Dec 29