Bug 76666 - [Chromium] Ganesh's Texture Cache is too small
Summary: [Chromium] Ganesh's Texture Cache is too small
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Canvas (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Jeff Timanus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-19 14:47 PST by Jeff Timanus
Modified: 2012-01-27 15:42 PST (History)
6 users (show)

See Also:


Attachments
Patch (1.59 KB, patch)
2012-01-19 14:52 PST, Jeff Timanus
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Timanus 2012-01-19 14:47:31 PST
The current Ganesh texture cache is initialized to cache no more than 50 Mb of texture data.  For some demos this is too constrained.

See parallel tracking issue:  crbug.com/110468
Comment 1 Jeff Timanus 2012-01-19 14:52:13 PST
Created attachment 123201 [details]
Patch
Comment 2 Vangelis Kokkevis 2012-01-19 22:27:12 PST
Comment on attachment 123201 [details]
Patch

I would feel more comfortable increasing the cache size if we were able to clear the cache when a tab is hidden like we do for the compositor.  In order to do that we may need to switch to using a shared graphics context per webview instead of renderer process or track how many tabs the renderer is dealing with and flush the cache when they are all hidden.

Alternatively, would it be possible to age textures in the cache so that we only evict ones that haven't been used for a while and use this texture limit as a soft limit that can be exceeded if more space is needed to keep the contents of a single frame?

Longer term we need to have a better strategy for doing global tracking of memory like nduca@ suggests.
Comment 3 Brian Salomon 2012-01-20 05:59:05 PST
(In reply to comment #2)
> (From update of attachment 123201 [details])
> I would feel more comfortable increasing the cache size if we were able to clear the cache when a tab is hidden like we do for the compositor.  In order to do that we may need to switch to using a shared graphics context per webview instead of renderer process or track how many tabs the renderer is dealing with and flush the cache when they are all hidden.
> 
> Alternatively, would it be possible to age textures in the cache so that we only evict ones that haven't been used for a while and use this texture limit as a soft limit that can be exceeded if more space is needed to keep the contents of a single frame?
> 
> Longer term we need to have a better strategy for doing global tracking of memory like nduca@ suggests.


We could make the cache size be a hard limit but periodically walk the cache and purge anything that hasn't been used in a while even when we are under-budget.
Comment 4 Jeff Timanus 2012-01-24 14:56:53 PST
Comment on attachment 123201 [details]
Patch

From the discussion we had offline today, I think we should let this patch through.

The plan is to introduce the capability of explicitly purging the Ganesh texture cache when all of the tabs associated with a render process have been backgrounded/hidden.
Comment 5 Jeff Timanus 2012-01-27 14:24:32 PST
Can a reviewer please have a look at this change, and mark it cq+?
Comment 6 Stephen White 2012-01-27 15:21:47 PST
Comment on attachment 123201 [details]
Patch

OK.  r=me
Comment 7 WebKit Review Bot 2012-01-27 15:42:19 PST
Comment on attachment 123201 [details]
Patch

Clearing flags on attachment: 123201

Committed r106164: <http://trac.webkit.org/changeset/106164>
Comment 8 WebKit Review Bot 2012-01-27 15:42:24 PST
All reviewed patches have been landed.  Closing bug.