[Webkit-unassigned] [Bug 90721] New: Don't destory the decoded data of an image if WebKit is about to render the image.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Jul 7 00:08:43 PDT 2012


           Summary: Don't destory the decoded data of an image if WebKit
                    is about to render the image.
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Images
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: luxtella at company100.net

When the cache capacity of MemoryCache is exceeded, decoded data of all 
CachedImages are destroyed. Even the images inside the viewport are destroyed.
However, if the images need to be rendered again due to scoll events or
animation, they must be decoded again. As an extreme case, if there is an animation
with an image when MemoryCache is almost full, the image must be decoded every
frame. This slows down animation and needlessly consumes CPU cycles.

Therefore, it is better not to destory the decoded data of an image if the image
is inside the viewport because there is high chance that the image neeeds to be
rendered again soon. This patch reduce the unnecessary repetition of image decoding
on low memory, and also relieve the memory fragmentation because it avoids reallocation
of image frames.

In addition, there is another positive side effect. Currently,
CachedImageClient::willRenderImage() is used only to determine if GIF animation needs
to be paused or not in CachedImage::shouldPauseAnimation(). This patch makes
GIF animation outside the viewort be paused.

This is also a prerequisite for parallel image decoders. Because parallel image
decoders decode an image asynchronously, clients cannot render the image at the time
when the request is made. Clients can draw the image later after receiving image
decoding complete notification. However, there is a problem because MemoryCache can 
destroy the decoded data before clients actually render the image. So parallel image decoders
must prevent the decoded data from being destroyed if the image will be rendered

This patch may consume a little more memory, but furtunately the peak memory usage
is almost the same.

Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

More information about the webkit-unassigned mailing list