[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:42:14 PDT 2012


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





--- Comment #26 from Eric Penner <epenner at chromium.org>  2012-09-04 18:42:26 PST ---
> > Source/WebCore/platform/graphics/chromium/cc/CCLayerTreeHostImpl.h:62
> >      virtual void postAnimationEventsToMainThreadOnImplThread(PassOwnPtr<CCAnimationEventsVector>, double wallClockTime) = 0;
> 
> Yes -- we could communicate the list of destroyed backings to the main thread at commit time -- we would call getAndClearEvictedBackings on the impl thread and communicate them via scheduledActionBeginFrame.  I had originally started with this scheme, and then abandoned it because the implementation was getting complicated -- copying the set of backings to and from the main thread was involved.

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

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

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

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