Recent changes to the DrawingBuffer class to add antialiasing support to the accelerated 2D canvas code path had some bugs and were illegally using certain enums. These issues need to be fixed and the Chromium port implemented.
Created attachment 80159 [details] Patch
Comment on attachment 80159 [details] Patch Thanks!
Comment on attachment 80159 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=80159&action=review > Source/WebKit/chromium/ChangeLog:10 > + GL_CHROMIUM_framebuffer_multisample) through WebGraphicsContext3D. Not a blocker, but I'm not sure I understand why we don't plumb through the ANGLE extensions verbatim. Feel free to de-confuse me at your convenience. :)
Comment on attachment 80159 [details] Patch R=me. I'm also curious about the extension name mapping.
Committed r76717: <http://trac.webkit.org/changeset/76717>
(In reply to comment #3) > (From update of attachment 80159 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=80159&action=review > > > Source/WebKit/chromium/ChangeLog:10 > > + GL_CHROMIUM_framebuffer_multisample) through WebGraphicsContext3D. > > Not a blocker, but I'm not sure I understand why we don't plumb through the ANGLE extensions verbatim. Feel free to de-confuse me at your convenience. :) I don't remember why we decided to expose a different extension than GL_ANGLE_framebuffer_multisample and GL_ANGLE_framebuffer_blit from the command buffer code. The ANGLE extension is written against OpenGL ES 2.0, and maybe we wanted slightly different or relaxed semantics so that we didn't have to have absolutely identical behavior between desktop and OpenGL ES 2.0 implementations. CC'ing Gregg in case he remembers.
http://trac.webkit.org/changeset/76717 might have broken Qt Linux Release