With a recent nightly, these two WebGL demos show bad flickering: http://plopbyte.net/?page_id=111/ http://www.cubicvr.org/CubicVR.js/LandscapeTest1.html
My graphics hardware: ATI Radeon HD 2600 XT: Chipset Model: ATI Radeon HD 2600 Type: GPU Bus: PCIe Slot: Slot-1 PCIe Lane Width: x16 VRAM (Total): 256 MB Vendor: ATI (0x1002) Device ID: 0x9588 Revision ID: 0x0000 ROM Revision: 113-B1480A-252 EFI Driver Version: 01.00.252 Displays: Cinema HD Display: Resolution: 1920 x 1200 Pixel Depth: 32-Bit Color (ARGB8888) Main Display: Yes Mirror: Off Online: Yes Rotation: Supported DELL 2005FPW: Resolution: 1680 x 1050 @ 60 Hz Pixel Depth: 32-Bit Color (ARGB8888) Mirror: Off Online: Yes Rotation: Supported
This is is particularly bad: http://www.cubicvr.org/CubicVR.js/ObjectCompositeTest.html
This regressed in http://trac.webkit.org/changeset/56872 Performance in general on my machine is much worse after this change.
Can you run the demo with {antialias: false} for context attributes? And what's the performance like?
Forget about the previous comments. I see your card is ATI, for which the antialias is false.
For example, when http://www.cubicvr.org/CubicVR.js/ObjectCompositeTest.html is loading, entire parts of the scene, like the walls and columns, flicker in and out, and the animation overall is jerky. That didn't happen prior to r56872.
I had a quick look at the patch. Seems like the difference (for your machine) is the stencil is on. Can you try the demo with {stencil: false} in context creation and let me know the performance?
This also happens for me on two different machines, both of which have different ATI chipsets. It looks like your logic for deciding how to deal with the textures is flipping frame-to-frame or something like that. This needs to be fixed ASAP. If you can't determine the root cause, please disable whatever is causing the flicker on ATI cards in Safari.
I don't have access to a machine with ATI card, so if anyone with ATI card can run the demo with {stensil: false} at content creation and let me know if it solves the performance issue, then I'll know what to do.
See https://bugs.webkit.org/show_bug.cgi?id=40090. Hopefully the landing of a patch there will resolve this issue.
Yes, that patch may resolve the issue, but I assume the problem would return if you turn on stencil in your content. So we really need to understand why stencil being on causes the flicker
(In reply to comment #11) > Yes, that patch may resolve the issue, but I assume the problem would return if you turn on stencil in your content. So we really need to understand why stencil being on causes the flicker I tried on kbr's Mac which has ATI card and couldn't reproduce the flicking. When the patch lands and either you or Simon can confirm it does resolve the issue, then we should file a driver bug to Apple.
(In reply to comment #11) > Yes, that patch may resolve the issue, but I assume the problem would return if you turn on stencil in your content. So we really need to understand why stencil being on causes the flicker One thing we could do is use something other than GL_DEPTH24_STENCIL8_EXT for certain ATI cards when a user requests stencil buffer.
Patch for https://bugs.webkit.org/show_bug.cgi?id=40090 landed last night. Please verify if the flicking is gone. We couldn't reproduce it on our side.
There is no improvement in the flickering.
http://www.cubicvr.org/CubicVR.js/ObjectCompositeTest.html doesn't work at all for me in a recent nightly.
(In reply to comment #15) > There is no improvement in the flickering. That's really weird. Because with antialias==false and stencil==false, WebGL should be the same with/without http://trac.webkit.org/changeset/56872.
(In reply to comment #17) > (In reply to comment #15) > > There is no improvement in the flickering. > > That's really weird. Because with antialias==false and stencil==false, WebGL should be the same with/without http://trac.webkit.org/changeset/56872. (In reply to comment #16) > http://www.cubicvr.org/CubicVR.js/ObjectCompositeTest.html doesn't work at all for me in a recent nightly. This is also weird. I just synced with the codebase and built webkit. The demo worked fine on my side.
FYI, we're trying to schedule some time in the Apple Compatibility Lab to diagnose this on the hardware in questions.
zmo and I tracked down the regression to the moving of the ensureContext call in GraphicsContext3D::prepareTexture (GraphicsContext3DMac.mm) into the "if (m_attrs.antialias)" block in bug 33416. Bug 36908 fixed part of this regression (the moving of a glFinish call into the same block) but not this part. svn diff follows; a patch will be filed shortly. Index: WebCore/platform/graphics/mac/GraphicsContext3DMac.mm =================================================================== --- WebCore/platform/graphics/mac/GraphicsContext3DMac.mm (revision 61422) +++ WebCore/platform/graphics/mac/GraphicsContext3DMac.mm (working copy) @@ -383,8 +383,8 @@ void GraphicsContext3D::prepareTexture() { + ensureContext(m_contextObj); if (m_attrs.antialias) { - ensureContext(m_contextObj); ::glBindFramebufferEXT(GL_READ_FRAMEBUFFER_EXT, m_multisampleFBO); ::glBindFramebufferEXT(GL_DRAW_FRAMEBUFFER_EXT, m_fbo); ::glBlitFramebufferEXT(0, 0, m_currentWidth, m_currentHeight, 0, 0, m_currentWidth, m_currentHeight, GL_COLOR_BUFFER_BIT, GL_LINEAR);
Created attachment 59149 [details] patch
Looks good.
Committed manually: http://trac.webkit.org/changeset/61432
Please copy the ChangeLog into the commit message. Tools like "webkit-patch land" can help do that for you.