n
It seems that ANGLE clamps GL_STENCIL_VALUE_MASK, GL_STENCIL_BACK_VALUE_MASK, GL_STENCIL_WRITEMASK and GL_STENCIL_BACK_WRITEMASK values into max integer, which results in the value change(0xffffffff --> 0x7fffffff) unintentionally.
Created attachment 260737 [details] Patch
Without this patch, fast/canvas/webgl/gl-get-calls.html fails on ANGLE backed OpenGL ES platform.
Comment on attachment 260737 [details] Patch We can apply this in WebKit, but you really need the change to be made in ANGLE. Also, is there a way to test this?
(In reply to comment #4) > Comment on attachment 260737 [details] > Patch > > We can apply this in WebKit, but you really need the change to be made in > ANGLE. Also, is there a way to test this? Ok then, I think it would be safe to commit this patch after landed on ANGLE project first. I believe there is no way to test this because no ports are using ANGLE as its OpenGL implementation but mine. My team's port is using ANGLE backed OpenGL APIs so I could find this bug. Anyway, thanks for review!
ANGLE seems implemented correctly based on the OpenGL ES 3.0 spec. So this patch should be abandoned. Instead, I'm trying to modify fast/canvas/webgl/gl-get-calls.html at https://bugs.webkit.org/show_bug.cgi?id=149174
(In reply to comment #6) > ANGLE seems implemented correctly based on the OpenGL ES 3.0 spec. > So this patch should be abandoned. > > Instead, I'm trying to modify fast/canvas/webgl/gl-get-calls.html at > https://bugs.webkit.org/show_bug.cgi?id=149174 Review from an ANGLE people. https://chromium-review.googlesource.com/#/c/299564/