687831 - Flickering & Broken Keyboard/Mouse Events

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Bobby Richter [:secretrobotron]]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Bobby, what are he build IDs of those nightlies in your case?  Is the issue Linux-specific?

Comment 2

[Bobby Richter [:secretrobotron]]

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.

Comment 3

[Bobby Richter [:secretrobotron]]

Updated to 10.0a1, problem still exists. Painful to use.

Comment 4

[Bobby Richter [:secretrobotron]]

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?

Comment 5

[Bobby Richter [:secretrobotron]]

Definitely layers_accel problem. Disabled, everything responds fine.

Comment 6

[Joe Drew (not getting mail)]

We don't use layers acceleration by default on X, right?

Comment 7

[Benoit Jacob [:bjacob] (mostly away)]

Not yet, but we would like to do it ASAP, so this bug matters.

Comment 8

[Karl Tomlinson (:karlt)]

(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

Comment 9

[Karl Tomlinson (:karlt)]

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.

Comment 10

[Karl Tomlinson (:karlt)]

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

Comment 11

[Karl Tomlinson (:karlt)]

Attachment: remove unused gIsChromium

A little cleanup in preparation.

Comment 12

[Karl Tomlinson (:karlt)]

gIsChromium for VirtualBox was added but not used in bug 575469.
http://hg.mozilla.org/mozilla-central/rev/23b8e7fd1794

Comment 13

[Karl Tomlinson (:karlt)]

Attachment: 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.

Comment 14

[Karl Tomlinson (:karlt)]

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

Comment 15

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/eb7bcfee6a5d
https://hg.mozilla.org/mozilla-central/rev/5f422778766a