[Webkit-unassigned] [Bug 64613] Use supported framebuffer renderbuffer mode.

[bugzilla-daemon at webkit.org]

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





--- Comment #11 from Vangelis Kokkevis <vangelis at chromium.org>  2011-07-25 10:10:57 PST ---
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > If that fixes things, great.  Otherwise (or until then) we should be using DrawingBuffer.
> > 
> > Not sure I understand the objection to this patch though.  If appears to fix a path that's already there but is not coded the right way.  If a later change simplified things, that's even better, but why not fix now something we know is broken?
> 
> The patch isn't wrong, but it's a symptom of a greater issue that this code is using a completely untested codepath that breaks all the time.  We typically require tests for patches because patching untested code is a large waste of effort.  If this code was using the same code as the test canvas 2d path, then it wouldn't have to deal with this issue and it wouldn't suffer from the other breakages.

The accelerated drawing path doesn't necessarily require its own tests.  We just need to start running DRT with the --accelerated-drawing flag to make sure there are no regressions.

There is some refactoring work going on both to make the DrawingBuffer less canvas2d-specific and to move the management of the buffers into Ganesh. Neither of these changes is going to make M14 but it would be a shame if the accelerated drawing option (which otherwise works modulo a couple more regression fixes that are in review) doesn't make it and has to be removed. I would consider this as a short term fix to meet our ship deadline.  It is after an improvement over code that's already been checked in and is known broken.

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