[Webkit-unassigned] [Bug 95057] [chromium] Allow impl-thread deletion of only some resources

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Sep 4 18:49:50 PDT 2012


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





--- Comment #27 from Christopher Cameron <ccameron at chromium.org>  2012-09-04 18:50:02 PST ---
(In reply to comment #26)
> I was thinking more along the lines of notifying the main thread so it could do the memory reduction and then push the updates across like it already does. Currently this would require a full commit though, and AFAIU there is a problem with that for invisible tabs? If we created custom impl-side objects for each texture we could also just push the ids across in a custom 'mini-commit'.

Ah, one of the goals is to be able to adjust memory without going back to the main thread (so we can very quickly adjust memory without getting blocked on JS, etc).  There are some things that are preventing this from always being the case ATM (visibility messages being synchronous, etc).

> > In the intervening iteration, it looks like it's not terribly complicated.  That said, there was some discussion of wanting the PTM to have a mutex for moving towards impl-side painting.  I'm very open to changing back to the scheme of passing the set of evicted textures to the main thread, but I'm getting a bit worried about vascilating too much before checking anything in.
> 
> Looks like you have buy-in from all the feedback. All I'd say is that the impl-side painting threading issues are quite different than the issues this is solving, so the stuff behind the mutex would be very different I think. Anyway, I'm a bit late to the party to request huge changes, so as long as reviewers are okay with it then that's fine with me.

Yes, you're right about the different mutex structure for the different purposes.  I'm strongly considering re-examining the "send the set to the main thread" scheme (to avoid the lock), but I'll land this first and then tweak it.

> > I wanted to name this as reduceMemoryOnImplThread because that's what the function will do in a subsequent change (I renamed a few things from "clear all" to "reduce").
> 
> Ah okay, if follow up CLs will fix then np, and consider removing "OnImplThread" for main-thread-blocked functions as well (if you agree with that bit - I'm not sure of the convention for that elsewhere).

Oh -- I like the convention (and I think this CL follows it -- reduceMemoryOnImplThread doesn't block main thread but reduceMemory does).

-- 
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