[Webkit-unassigned] [Bug 157857] New: PDFDocumentImage should not create a cached image larger than 4MB pixels

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed May 18 12:41:32 PDT 2016


https://bugs.webkit.org/show_bug.cgi?id=157857

            Bug ID: 157857
           Summary: PDFDocumentImage should not create a cached image
                    larger than 4MB pixels
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Images
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: sabouhallawa at apple.com

This has been causing a memory jetsam on iOS devices when opening a large single page PDF file and zooming. When zooming on this PDF, PDFDocumentImage::draw() tries to update its cached image first. The purpose of this caching is to make redrawing the same part of the PDF document faster. The problem is the image we cache for a single tile has to be scaled with the current zooming factor. At the maximum zooming level, the image size is a little bit larger than (4000x4000) pixels. This requires 4000x4000x4=64MB.

This is a huge memory to be allocated for a single tile especially on low-memory machine or devices. Luckily PDFDocumentImage::draw() can fallback peacefully if the cached image can't be created for any reason. All it does is transformContextForPainting() and then  drawPDFPage() which will draw exactly the same thing the cached image would have drawn if it was created. 

The fix it to prevent creating the cached image for the PDFDocumentImage if its size is more than 4B pixels. The only drawback for this fix is the render will be a little bit slower when zooming on a PDFDocumentImage. But with lower zooming factors, the caching will still happen and the rendering/scrolling perf will not be affected.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160518/f57e51a8/attachment.html>


More information about the webkit-unassigned mailing list