Flickering & Broken Keyboard/Mouse Events

RESOLVED FIXED in mozilla17



6 years ago
5 years ago


(Reporter: secretrobotron, Assigned: karlt)


(Blocks: 1 bug)

Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)



(2 attachments)



6 years ago
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

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

Comment 2

6 years ago
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

6 years ago
Updated to 10.0a1, problem still exists. Painful to use.

Comment 4

6 years ago
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

6 years ago
Definitely layers_accel problem. Disabled, everything responds fine.


6 years ago
Blocks: 594876
Component: XUL → Graphics
QA Contact: xptoolkit.widgets → thebes
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.

Comment 8

5 years ago
(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."
Blocks: 675474

Comment 9

5 years ago
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

5 years ago
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."
QA Contact: karlt


5 years ago
Depends on: 778031

Comment 11

5 years ago
Created attachment 646454 [details] [diff] [review]
remove unused gIsChromium

A little cleanup in preparation.
Assignee: nobody → karlt

Comment 12

5 years ago
gIsChromium for VirtualBox was added but not used in bug 575469.

Comment 13

5 years ago
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


5 years ago
QA Contact: karlt


5 years ago


5 years ago
Attachment #646454 - Flags: review?(matt.woodrow)


5 years ago
Attachment #646455 - Flags: review?(matt.woodrow)
Attachment #646454 - Flags: review?(matt.woodrow) → review+
Attachment #646455 - Flags: review?(matt.woodrow) → review+

Comment 14

5 years ago

Flags: in-testsuite-
Hardware: x86 → All
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
You need to log in before you can comment on or make changes to this bug.