[Webkit-unassigned] [Bug 170640] New: Do not delete asynchronously decoded frames for large images if their clients are in the viewport

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Apr 8 00:59:46 PDT 2017


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

            Bug ID: 170640
           Summary: Do not delete asynchronously decoded frames for large
                    images if their clients are in the viewport
           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

Enabling the async image decoding for large images causes screen flickering in many web pages and during interacting with the page. The main reason for this flickering is destroying the decoded frames by the MemoryCache because of memory pressure. A common example is drawing an image which spans multiple tiles. Since drawing to tiles happens in different drawing phases, MemoryCache can destroy decoded frames between two drawing phases. In this example this can lead to Infinitis repaint-draw loop. Assume the following concrete example:

An image M  is drawn on multiple tiles T1 and T2

1. T1 draws M, no decoded frame is found, request async decoding, nothing is drawn.
2. T2 draws M, no decoded frame is found but it is already being decoded, nothing is drawn.
3. M finishes decoded, the split rectangles of M in T1 and T2 are repainted.
4. T1 draws M,  decoded frame is found, part of the image is drawn.
5. MemoryCache asks M to destroy its decoded frame.
6. T2 draws M,  no decoded frame is found, request async decoding, nothing is drawn.
7. M finishes decoded, the rectangle of M in T1 and T2 is repainted.
8. Go to step 1.

To fix this problem the decoded frames of the large images in the current viewport should not be deleted by the MemoryCache. This makes sense because the viewport is drawn, the same images will be re-decoded.

We need to implement the opposite of the pausing the animated images. When the large image decoded its frame it is going to notify its CachedImageClient which is RenderElement in the case of image element and css background image. The RenderElement will check whether it's in the viewport and if is, it is going to add itself to the list of RendererWithPermanentImageFrame and setHasPermanentImageFrame(true). When the RenderView::updateVisibleViewportRect(), we are going to check if any of the RendererWithPermanentImageFrame went outside the viewport and setHasPermanentImageFrame(false) of the image so the decoded can be deleted if it is requested to.

-- 
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/20170408/15598f4b/attachment-0001.html>


More information about the webkit-unassigned mailing list