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."
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.
"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
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.
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