[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
https://bugs.webkit.org/show_bug.cgi?id=90721
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
soon.
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