[Webkit-unassigned] [Bug 76239] DrawingBuffer is not cleared correctly

[bugzilla-daemon at webkit.org]

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





--- Comment #15 from Kenneth Russell <kbr at google.com>  2012-01-19 12:19:23 PST ---
(In reply to comment #14)
> > I don't see how fixing Bug 76225 will affect the execution of fast/canvas/webgl/drawingbuffer-test.html. There is no JavaScript-level garbage collection involved when the canvas's width and height are changed. Bug 76255 will only release WebGL resources more eagerly when the page is unloaded.
> 
> Does the cases 'drawingbuffer-static-canvas-test' and 'drawingbuffer-test' was ran in one renderer process in the test framework?
> 
> If yes, it's similar to refresh the page: the previously used drawingbuffer was not released and then the next case have no enough buffer to use. So a gc or resource release is needed.
> 
> In my own test results, these 2 cases running in one tab in turn are in one renderer process.
> Could you please help check it in the test server?

Yes, it looks like they run in the same renderer process.

I see what is happening -- we are hitting the s_maximumResourceUsePixels limit in the DrawingBuffer code when running almost any other test in the same renderer process as drawingbuffer-test.html. When just running the layout tests, it's sufficient to run just fast/canvas/webgl/canvas-test.html and fast/canvas/webgl/drawingbuffer-test.html in the same invocation of run-webkit-tests to provoke the failure.

While fixing Bug 76562 will mask this problem, there is a deeper issue; the WebGL context must retry the allocation of the back buffer at a smaller size if it fails. There is really no provision in the spec for the context's back buffer shrinking to 0x0 in response to resizing of the canvas. I've filed https://bugs.webkit.org/show_bug.cgi?id=76654 to track this issue.

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