[Webkit-unassigned] [Bug 76225] Release WebGL contexts eagerly

Fri Jan 20 12:30:02 PST 2012

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

--- Comment #6 from Kenneth Russell <kbr at google.com>  2012-01-20 12:30:02 PST ---
(In reply to comment #5)
> FrameDestructionObserver doesn't make sense here because the frame seems not be destroyed if refreshing a page or switching to a new case. I find that when refreshing or a new page, Frame calls the 'detach' function of the document before the new dom tree is created. So i think in HTMLCanvasElement, by overriding the virtual 'detach' function, the WebGLRenderingContext and drawingbuffer can be freed. What's your opinion?

I've talked with jamesr about this and it sounds like the solution is not this simple. It's valid, and common in sophisticated web applications, to have two documents (for example, using window.open()) and move Canvases around between them. Using Canvas' detach() method as a hint, even just to "lose" the WebGLRenderingContext, will be too much of a penalty.

It seems that the only true way to determine that a WebGLRenderingContext or other DOM-related object is really unreachable is for all of its JavaScript references to go away. Unfortunately, as we've seen, doing so requires full GCs to run, and these are expensive.

A couple of other suggestions were discussed. One was to modify DumpRenderTree to force full GCs between test runs. This won't work well because it will only fix layout test runs. The WebGL conformance tests exhibit the same problem and run within the full browser.

Another suggestion was to use V8's V8::AdjustAmountOfExternalAllocatedMemory() API to artificially increase heap pressure when a WebGLRenderingContext is created. This, however, will cause more full GCs to be performed, and this is a really bad idea for the overall performance of web applications. Also, it's a solution that will only work on one JS engine.

There was an idea to watch for calls to the detach() method of the owning Document of the Canvas (rather than the Canvas itself), and use those as heuristics for when to lose the WebGLRenderingContext.

Another idea, possibly the most principled, would be to watch for destruction of the ScriptExecutionContext (see ContextDestructionObserver in ActiveDOMObject.h) and force loss of the WebGL context when that happens. From what I have heard, it may still be possible for another ScriptExecutionContext to have a reference to the same DOM object, but this is probably not a common case.

In summary, though, making correct WebGL test execution depend on eager destruction of the WebGL contexts is not going to be a reliable solution. At this point, I firmly believe that fixing Bug 76654 (reallocate the WebGL back buffer at a smaller size if allocation fails) is the best solution and should be the top priority.

> Another question, is it enough to do the test 'fast/canvas/webgl' of layout tests for this issue?

A full layout test run would definitely be required. Doing full layout test runs should be a habit.

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