[webkit-changes] [208032] trunk

2016-10-27 Thread mmaxfield
Title: [208032] trunk








Revision 208032
Author mmaxfi...@apple.com
Date 2016-10-27 22:28:55 -0700 (Thu, 27 Oct 2016)


Log Message
Teach WebGL code about new buffer targets in WebGL2
https://bugs.webkit.org/show_bug.cgi?id=163924

Reviewed by Dean Jackson.

Source/WebCore:

WebGL 2 adds new buffer targets. Instead of completely reimplementing
the functions again for WebGL 2, we can simply check if we are using
a new kind of context to conditionally enable support.

Test: fast/canvas/webgl/webgl2-buffer-targets.html

* html/canvas/WebGL2RenderingContext.h:
* html/canvas/WebGL2RenderingContext.idl:
* html/canvas/WebGLBuffer.cpp:
(WebCore::WebGLBuffer::associateBufferDataImpl):
(WebCore::WebGLBuffer::associateBufferSubDataImpl):
(WebCore::WebGLBuffer::setTarget):
* html/canvas/WebGLBuffer.h:
* html/canvas/WebGLRenderingContextBase.cpp:
(WebCore::WebGLRenderingContextBase::bindBuffer):
(WebCore::WebGLRenderingContextBase::getBufferParameter):
(WebCore::WebGLRenderingContextBase::validateBufferDataParameters):
* html/canvas/WebGLRenderingContextBase.h:

LayoutTests:

* fast/canvas/webgl/bufferData-offset-length.html:
* fast/canvas/webgl/webgl2-buffer-targets-expected.txt: Added.
* fast/canvas/webgl/webgl2-buffer-targets.html: Added.

Modified Paths

trunk/LayoutTests/ChangeLog
trunk/LayoutTests/fast/canvas/webgl/bufferData-offset-length.html
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/html/canvas/WebGL2RenderingContext.h
trunk/Source/WebCore/html/canvas/WebGL2RenderingContext.idl
trunk/Source/WebCore/html/canvas/WebGLBuffer.cpp
trunk/Source/WebCore/html/canvas/WebGLBuffer.h
trunk/Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp
trunk/Source/WebCore/html/canvas/WebGLRenderingContextBase.h


Added Paths

trunk/LayoutTests/fast/canvas/webgl/webgl2-buffer-targets-expected.txt
trunk/LayoutTests/fast/canvas/webgl/webgl2-buffer-targets.html




Diff

Modified: trunk/LayoutTests/ChangeLog (208031 => 208032)

--- trunk/LayoutTests/ChangeLog	2016-10-28 04:30:22 UTC (rev 208031)
+++ trunk/LayoutTests/ChangeLog	2016-10-28 05:28:55 UTC (rev 208032)
@@ -1,3 +1,14 @@
+2016-10-27  Myles C. Maxfield  
+
+Teach WebGL code about new buffer targets in WebGL2
+https://bugs.webkit.org/show_bug.cgi?id=163924
+
+Reviewed by Dean Jackson.
+
+* fast/canvas/webgl/bufferData-offset-length.html:
+* fast/canvas/webgl/webgl2-buffer-targets-expected.txt: Added.
+* fast/canvas/webgl/webgl2-buffer-targets.html: Added.
+
 2016-10-27  Simon Fraser  
 
 If an animation's keyframes affect stacking context properties, create stacking context while the animation is running


Modified: trunk/LayoutTests/fast/canvas/webgl/bufferData-offset-length.html (208031 => 208032)

--- trunk/LayoutTests/fast/canvas/webgl/bufferData-offset-length.html	2016-10-28 04:30:22 UTC (rev 208031)
+++ trunk/LayoutTests/fast/canvas/webgl/bufferData-offset-length.html	2016-10-28 05:28:55 UTC (rev 208032)
@@ -39,7 +39,7 @@
 debug("");
 
 if (window.internals)
-		internals.setWebGL2Enabled(true);
+	internals.setWebGL2Enabled(true);
 gl = initWebGL("example", "vshader", "fshader", [ "vPosition", "index" ],
[ 1, 1, 1, 1 ], 1, null, true);
 
@@ -80,6 +80,8 @@
 checkRedValue(10, 10, 0, "Left half of canvas should be filled");
 checkRedValue(30, 10, 255, "Right half of canvas should be empty");
 
+gl.deleteBuffer(vertexObject);
+
 function checkRedValue(x, y, value, msg) {
 gl.clear(gl.COLOR_BUFFER_BIT | gl.DEPTH_BUFFER_BIT);
 gl.drawArrays(gl.TRIANGLES, 0, 6);


Added: trunk/LayoutTests/fast/canvas/webgl/webgl2-buffer-targets-expected.txt (0 => 208032)

--- trunk/LayoutTests/fast/canvas/webgl/webgl2-buffer-targets-expected.txt	(rev 0)
+++ trunk/LayoutTests/fast/canvas/webgl/webgl2-buffer-targets-expected.txt	2016-10-28 05:28:55 UTC (rev 208032)
@@ -0,0 +1,88 @@
+CONSOLE MESSAGE: line 55: WebGL: INVALID_ENUM: bindBuffer: invalid target
+CONSOLE MESSAGE: line 57: WebGL: INVALID_ENUM: bufferData: invalid target
+CONSOLE MESSAGE: line 55: WebGL: INVALID_ENUM: bindBuffer: invalid target
+CONSOLE MESSAGE: line 57: WebGL: INVALID_ENUM: bufferData: invalid target
+CONSOLE MESSAGE: line 55: WebGL: INVALID_ENUM: bindBuffer: invalid target
+CONSOLE MESSAGE: line 57: WebGL: INVALID_ENUM: bufferData: invalid target
+CONSOLE MESSAGE: line 55: WebGL: INVALID_ENUM: bindBuffer: invalid target
+CONSOLE MESSAGE: line 57: WebGL: INVALID_ENUM: bufferData: invalid target
+CONSOLE MESSAGE: line 55: WebGL: INVALID_ENUM: bindBuffer: invalid target
+CONSOLE MESSAGE: line 57: WebGL: INVALID_ENUM: bufferData: invalid target
+CONSOLE MESSAGE: line 55: WebGL: INVALID_ENUM: bindBuffer: invalid target
+CONSOLE MESSAGE: line 57: WebGL: INVALID_ENUM: bufferData: invalid target
+Checks that using WebGL 2 buffer targets don't cause errors
+
+On success, you will see a series of "PASS" messages, 

[webkit-changes] [208313] trunk

2016-11-02 Thread mmaxfield
Title: [208313] trunk








Revision 208313
Author mmaxfi...@apple.com
Date 2016-11-02 17:05:12 -0700 (Wed, 02 Nov 2016)


Log Message
[iOS] [WebGL] Multisample resolve step may operate on stale data
https://bugs.webkit.org/show_bug.cgi?id=164347

Reviewed by Dean Jackson.

Source/WebCore:

When antialiasing is enabled, WebKit internally creates a multisampled FBO
and uses that as the target of all the drawing commands. Then, just before
we actually put the image on the glass, we perform a “resolve” step which
averages all the samples to create the final image. However, it appears
that this resolve step only waits for commands to complete which were
already submitted to the hardware. OpenGL is allowed (indeed, expected) to
batch up drawing commands in main memory so it can submit them to the
hardware in fewer batches, but this means that the hardware may not know
about all the commands that the application submitted. Because of this,
the data the resolve step saw is the result of only some of the previous
draw calls - not all of them.

This doesn’t occur on macOS because we have a different code path there
for performing the resolve step. On iOS 9 and below, WebKit didn’t
implement multisampling in WebGL at all, which explains why this only
occurs on iOS 10.

Luckily, the OpenGL command glFlush() is exactly designed to submit any
pending commands to the hardware.

Test: fast/canvas/webgl/multisample-resolve-consistency.html

* platform/graphics/opengl/GraphicsContext3DOpenGL.cpp:
(WebCore::GraphicsContext3D::resolveMultisamplingIfNecessary):

LayoutTests:

Issue many draw calls into a multisampled context, and then use glReadPixels()
to make sure that all the commands completed.

* fast/canvas/webgl/multisample-resolve-consistency-expected.txt: Added.
* fast/canvas/webgl/multisample-resolve-consistency.html: Added.

Modified Paths

trunk/LayoutTests/ChangeLog
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/platform/graphics/opengl/GraphicsContext3DOpenGL.cpp


Added Paths

trunk/LayoutTests/fast/canvas/webgl/multisample-resolve-consistency-expected.txt
trunk/LayoutTests/fast/canvas/webgl/multisample-resolve-consistency.html




Diff

Modified: trunk/LayoutTests/ChangeLog (208312 => 208313)

--- trunk/LayoutTests/ChangeLog	2016-11-02 23:30:16 UTC (rev 208312)
+++ trunk/LayoutTests/ChangeLog	2016-11-03 00:05:12 UTC (rev 208313)
@@ -1,3 +1,16 @@
+2016-11-02  Myles C. Maxfield  
+
+[iOS] [WebGL] Multisample resolve step may operate on stale data
+https://bugs.webkit.org/show_bug.cgi?id=164347
+
+Reviewed by Dean Jackson.
+
+Issue many draw calls into a multisampled context, and then use glReadPixels()
+to make sure that all the commands completed.
+
+* fast/canvas/webgl/multisample-resolve-consistency-expected.txt: Added.
+* fast/canvas/webgl/multisample-resolve-consistency.html: Added.
+
 2016-11-01  Sam Weinig  
 
 [WebIDL] Move interfaces and typed arrays over to JSDOMConvert


Added: trunk/LayoutTests/fast/canvas/webgl/multisample-resolve-consistency-expected.txt (0 => 208313)

--- trunk/LayoutTests/fast/canvas/webgl/multisample-resolve-consistency-expected.txt	(rev 0)
+++ trunk/LayoutTests/fast/canvas/webgl/multisample-resolve-consistency-expected.txt	2016-11-03 00:05:12 UTC (rev 208313)
@@ -0,0 +1,8 @@
+ Checks that multisample resolve has no timing issues
+PASS gl.getContextAttributes().antialias is true
+PASS gl.getError() is gl.NO_ERROR
+PASS gl.getError() is gl.NO_ERROR
+PASS successfullyParsed is true
+
+TEST COMPLETE
+


Added: trunk/LayoutTests/fast/canvas/webgl/multisample-resolve-consistency.html (0 => 208313)

--- trunk/LayoutTests/fast/canvas/webgl/multisample-resolve-consistency.html	(rev 0)
+++ trunk/LayoutTests/fast/canvas/webgl/multisample-resolve-consistency.html	2016-11-03 00:05:12 UTC (rev 208313)
@@ -0,0 +1,117 @@
+
+
+
+
+
+
+
+
+
+
+