A change on nightly between 08-24 and 08-25 caused pieces of my browser to start flickering. Entire chunks of a webpage or pieces of the browser UI may flicker when moving my mouse around or scrolling. Moreover, using the mouse and keyboard seems to be an entire event cycle behind. For example, assume my cursor is at the end of a textbox containing "lolcats r us". If I press ctrl+shift+left, nothing will happen, but if I press *anything* else afterwards, the highlight will suddenly be over "us". This doesn't just apply to highlighting. Simply moving the cursor around has the same effect. I've had similar experience with the mouse, where highlighting blocks of text is very difficult because the highlight while dragging is incorrect. I've tried reproducing something similar in other apps, but firefox seems to be the only thing with this problem.
Bobby, what are he build IDs of those nightlies in your case? Is the issue Linux-specific?
The build ID on the 25th nightly is " Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110825 Firefox/9.0a" Note: This happens on x86_64/i686. I don't really know if it's linux-specific since I have no other OS around me right now :(. My guess, though, is that it is.
Updated to 10.0a1, problem still exists. Painful to use.
This problem has now crept into my aurora stream. Effectively, I can't use firefox on my machine anymore. Now... that's a problem. Some debug help? Please?
Definitely layers_accel problem. Disabled, everything responds fine.
We don't use layers acceleration by default on X, right?
Not yet, but we would like to do it ASAP, so this bug matters.
(In reply to Bobby Richter [:bobby] from comment #0) > A change on nightly between 08-24 and 08-25 caused pieces of my browser to > start flickering. Likely a regression from bug 675474. Reverting to XSync from glXWaitX makes big improvements here with r600g. I fear this might be because "for pixmaps, dri2 glXWaitX() is a no-op: The X server side doesn't create a fake front, and the dri2 glx code hence can't send a dri2CopyRegion from front to fake front." http://lists.freedesktop.org/archives/mesa-dev/2011-June/008241.html
The drawable on the context is (typically) not a pixmap but a window, but the glxWaitX is still a no-op because dri2_drawable::have_fake_front is not set, which I expect is because the dri2_drawable does not have a DRI2BufferFrontLeft buffer. It does have a DRI2BufferBackLeft buffer. Taking the gIsATI path in GLContextProviderGLX::CreateForWindow to select a non double-buffered config activates glxWaitX. Even after a SwapBuffers on a context with a double-buffered config, there is still no front buffer on the dri2_drawable. I don't know why that would be.
dri2proto.text says: "2.5 Rendering to the X front buffer OpenGL allows the client to render to the front buffer, either by using a single-buffered configuration or but explicitly setting the draw buffer to GL_FRONT_LEFT. Not allowed! The client must ask for a fake front buffer, render to that and then use DRI2CopyRegion to copy contents back and forth between the fake front buffer and the real front buffer. When X and direct rendering to a front buffer is interleaved, it is the responsibility of the application to synchronize access using glXWaitGL and glXWaitX. A DRI2 implementation of direct rendering GLX, should use these enty points to copy contents back and forth to as necessary to ensure consistent rendering. " It seems that this is dealing with mixing X and GL rendering to the destination window. When the drawable is single buffered, Mesa's glXWaitX performs this operation and waits for a reply. We do not use X to render to the destination drawable, so I assume this copy is not required but waiting for the reply has the effect of syncing our drawing to the source pixmap. It seems it would be better for us to just use XSync. When this copy is not necessary, Mesa does nothing and our drawing to the source pixmap does not get synced. Again, we need to XSync ourselves when Mesa won't do this for us (even though it should according to the spec). I can't imagine how glXWaitX/GL could automatically handle mixing X and GL rendering with a double buffer destination window. It seems the application would need to copy between front and back or swap buffers between X and GL rendering. That may explain why this copy does not happen with double-buffered windows. FWIW, the spec goes on to say: "The client may also use the DRI2SwapBuffers function to request a swap of the front and back buffers. If the display server supports it, this operation may be preferred, since it may be easier and/or more performant for the server to perform a simple buffer swap rather than a blit."
Created attachment 646454 [details] [diff] [review] remove unused gIsChromium A little cleanup in preparation.
gIsChromium for VirtualBox was added but not used in bug 575469. http://hg.mozilla.org/mozilla-central/rev/23b8e7fd1794
Created attachment 646455 [details] [diff] [review] use XSync for glXWaitX with Mesa Depends on the path in bug 778031. It looks like Mesa's glXWaitX implementation is client side unless the context is indirect. XSync is not required if rendering is indirect but indirect rendering supports only GL 1.4, so we don't use it. I assume direct rendering with non-Mesa servers would require DRI2 support and I don't know that any non-Mesa servers would provide that, but checking the client string seems appropriate.
https://tbpl.mozilla.org/?tree=Try&rev=47e0b459eb76 https://hg.mozilla.org/integration/mozilla-inbound/rev/eb7bcfee6a5d https://hg.mozilla.org/integration/mozilla-inbound/rev/5f422778766a