xorg does not synchronize to vertical refresh

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please attach your X server configuration file (/etc/X11/xorg.conf) and X server log file (/var/log/Xorg.0.log) to the bug report as individual uncompressed file attachments using the "Attachment:" box below.

After attaching the information requested above, set the bug status to 'new' to signify that it is ready for triage / review. Thanks in advance.

I'm attaching the conf and log files from a Lenovo x60 tablet. The graphics hardware on this machine is "Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)".

I'd be happy to attach files from several other machines if you think it would be helpful..

repo

move a window around quickly and pay attention to edges of windows.

Unfortunately the xorg.conf you've included contains a lot of overrides for things xserver now autodetects, and it's possible some of your overrides could be causing these problems. I would encourage you to first reproduce this bug with a stock xorg.conf (i.e. move aside your existing xorg.conf and then generate a new one using `dexconf` (you might need to re-add some of your InputDevice settings, but keep the number of alterations minimal)).

In particular, doublecheck your vertical and horizontal sync rate settings, as those especially can cause problems like these.

You also mention that some are running compiz. It's hard to say without seeing screenshots, but there's already well known tearing issues with compiz with 3D apps (bug #96991) I can easily reproduce that on intel 945 hardware.

While it probably seems like this is an xserver bug since you're seeing it with multiple combinations of hardware and drivers, in my experience these issues tend to be highly driver-specific, and similarities in symptoms are often coincidental. Even if it does turn out to be a xserver bug, it's more likely to get addressed upstream if we treat each case separately as driver issues. So please file separate bug reports for each case, against the appropriate driver, attaching all relevant information (minimalized xorg.conf, Xorg.0.log, screenshots, etc.) See http://wiki.ubuntu.com/X/Reporting for tips on what information to include.

I realized I may have just misunderstood the report - is the complaint just that you don't like X's screen repainting algorithm? In that case, you'd probably be best to take that directly upstream to the xorg-devel@ mailing list, since that's probably not something we would/could address at the Ubuntu distro level.

My understanding of this is that it can't reasonably be done at an X level, although X provides the ability for apps to sync-to-vblank.

As I understand it, the problem with getting X to do this is that it'd have to check/sync for every drawing operation, making all drawing substantially slower. For some things (XVideo, for example) this can work, because the way Xv is used tends to be "draw this whole frame", so the overhead isn't bad. Regular drawing involves many, many operations to draw a single window, so the overhead becomes significant.

Now that compositing window managers are becoming widespread, this should be fixable. Composite allows you to do all the drawing offscreen, then the compositor draws the whole desktop to the screen in a single action, which can reasonably be synchronised with vblank. Compiz allows this.

Hah! Listen to Bryce, he knows more than I do :). That's a pretty cool screenshot, though.

The screenshot is pretty, but I think that's more of a gimp / screenshot issue than the one I'm talking about :)
I've attached a photo of my screen while dragging a window. The exposure time is about 6ms and shows the current "frame", which is torn, and an older frame which hasn't completely faded yet.

Based on Chris's comments, I'd say the bug is just invalid and we should wait for compiz to fix its sync issues?

lcampagn, how quickly were you moving the window at the time? I have to move the window pretty fast to get the distortion as bad as in the screenshot. I still notice it 'by eye' when moving windows normally, I can easily ignore it in daily use; does it tear to the degree in your screenshot during regular use? Also, what hardware are your other computers that have the issue? Do you use compiz on them? And are they running any restricted drivers?

I would like to ask upstream about this just to have their input on it, but before that I want to try and isolate our issue a bit more. It really could be that we have totally different bugs with the same symptoms, but from your screenshot, it seems the same to me, I just happened to be moving my window faster and in circles producing more exaggerated tears.

To recreate the screenshot, I use the Applications > Take screenshot with a delay of 3 seconds. After I click ok I then grab any window and quickly drag it in circles around my screen until the screenshot is taken.

I don't think it is only a compiz problem, because the screenshot I attached here is using the Vesa drivers. The next attachment will be my xorg.conf.

On Fri, Jul 11, 2008 at 11:52 AM, Dereck Wonnacott <email address hidden> wrote:
> lcampagn, how quickly were you moving the window at the time? I have to
> move the window pretty fast to get the distortion as bad as in the
> screenshot. I still notice it 'by eye' when moving windows normally, I
> can easily ignore it in daily use; does it tear to the degree in your
> screenshot during regular use?

It's not all that noticeable--I basically just kept swinging the mouse
around very quickly while snapping photos until I caught one that was
torn. If I take a screenshot using the same mouse motion, I get
roughly the same effect you saw. In general it's pretty easy to
ignore, but if you're aware of it, then even slow moving objects will
have a "rippling" effect on their edges. The distortion you see in
your screenshot occurs because the software that reads the contents of
the screen is too slow to take a full screenshot before the window has
moved several times, so what you see there isn't really related to
this bug. (I certainly never see tearing that bad)

The degree to which any system will show tearing will largely depend
on the vertical refresh rate of the monitor and the performance of the
system, but I doubt very much that anything like your screenshot is
actually visible on the screen--I've never caught a photo with more
than a single tear in it (although this is not impossible).

> Also, what hardware are your other
> computers that have the issue? Do you use compiz on them? And are they
> running any restricted drivers?

I have tried:
nVidia Corporation NV17 [GeForce4 MX 440] - restricted drivers, no compiz
nVidia Corporation NV43 [GeForce 6600] - restricted and OS drivers,
with and without compiz
Intel Corporation Mobile 945GM/GMS - "intel" driver, with and without compiz
Silicon Integrated Systems [SiS] 65x/M650/740 PCI/AGP - no compiz

> I would like to ask upstream about this just to have their input on it,
> but before that I want to try and isolate our issue a bit more. It
> really could be that we have totally different bugs with the same
> symptoms, but from your screenshot, it seems the same to me, I just
> happened to be moving my window faster and in circles producing more
> exaggerated tears.

I'd be interested to hear what upstream has to say, but I really
suspect Chris is correct--it is not reasonable for X to try to sync to
vblank unless it is rendering to an offscreen buffer, which is almost
the entire function of compiz. Once they have their sync issues sorted
out, this problem should be gone forever.

Q

Okay, based on the feedback it sounds like really this is more of a performance concern. In normal operations on a system with decent performance, the tearing is present but hardly noticeable, however on systems with worse performance (or under a large amount of load) the tearing can certainly be seen. I suspect we're going to just have to accept it as the way it works when in degraded circumstances, and focus on addressing the underlying performance issue, rather than fiddle with the drawing algorithm to hide the bad performance. As raof mentions, changing that algorithm probably would cause worse behavior in some other situation.

lcampagn, so I think you're right this can be closed, and instead focus on the compiz performance problem. Have you opened a bug about the sync problem against compiz? If not, please go ahead and do so.

In the mean time, if you do bring this issue up on the Xorg upstream mailing list, and get any further info that we may want to look at for ubuntu, please feel free to reopen this bug.