LWN: Comments on "LPC: 25 years of X"

Synchronous grabs

Ross — Sun, 11 Oct 2009 23:01:37 +0000

The article claims these are never used. That doesn't match my admitted fuzzy knowledge of the subject.

For example, I think these are the only way to implement "click to raise" on application windows in a window manager without eating the button clicks on application windows. I'm pretty sure that many window managers use it for such things and even the ICCCM says to do so (side note: can somebody please update it to cover things like this if there are known correct ways to do it).

Now I'm not saying it's a great mechanism, and it certainly isn't flexible . It would be much nicer to be able to intercept events to child windows even if they are owned by another client and replay any user-generated event to any child window and/or client.

In general I find the X11 event system to be complex and confusing: sometimes things are delivered to clients, sometimes windows, sometimes it matters what events are masked by parent windows, not to mention grabs by multiple clients (sometimes additional grabs fail silently, sometimes they generate a protocol error). Also, the use of timestamps to avoid race conditions seems kind of weak, and it's not immediately clear which situations require inspection of stamps, or what order they must be in. Things like the ICCCM could be improved to explain more of these situations, and libraries could do a better job of making it easy to do things the right way (Xlib hides some complexity poorly, and add a lot of it's own).

X: 25 years and still lacking vsync'ed double buffering

Ross — Sun, 11 Oct 2009 22:24:29 +0000

> They do. A *lot* depends on having that interval available.

Yes, but the delay between updates can be very small in comparison to what are needed for CRTs. This can even be taken advantage of with normal analog VGA connections to get a higher refresh rate and/or resolution with the same pixel clock (see reduced blanking modes).

> The common case is watching videos or playing games, where it's not cleared up on the next frame refresh because another update has happened in the meantime. It manifests itself as a consistent discontinuity in the image. It's greatly irritating.

Or it may slowly move up or down the screen. It can be very distracting in the right situation.

-Ross

X: 25 years and still lacking vsync'ed double buffering

Ross — Sun, 11 Oct 2009 22:18:22 +0000

But usually they retrace many strips of the screen in parallel (otherwise the refresh rate would be too slow). So it's not exactly a vertical retrace that you want to know about, but a way to avoid drawing operations during display updates.

X: 25 years and still lacking vsync'ed double buffering

Ross — Sun, 11 Oct 2009 22:09:35 +0000

I thought X drawing operations were are always supposed to be synched to screen refreshes. I guess that might be impractical if they take too long, but even so, you can draw into a pixmap and update the visible window with a copy operation. This should not flicker (though it may have tearing if there is constant motion and I'm wrong a about vsync).

X: 25 years and still lacking vsync'ed double buffering

kragil — Thu, 08 Oct 2009 07:52:51 +0000

Triple buffering, yeah!
It is fun to see that a concept that I used in the Amiga arcade games I wrote as a kid is now a solution to X problems.

It probably is true what they say, that most of hard CS problems were solved in the 60s (I just takes a few generations to implement them everywhere)

LPC: 25 years of X

oak — Wed, 07 Oct 2009 20:05:32 +0000

(This is not anymore that much related to X, but maybe here are also other
old Atari owners. I think this is kind of interesting also to others in
kind of a obscure "Oh Gosh, are people still doing stuff for
those" -way. :-))

There are no W users I know of, but I recently brushed the dust off the
code, updated it to build with latest GCC, liblua etc. and added Debian
packaging in case somebody wants to recapture the old feel of monochrome
graphics and W programming (it works on X using SDL):
http://koti.mbnet.fi/tammat/open.shtml#wws

And MiNT (the open source unix-like replacement for Atari TOS) is actually
still alive:
http://sparemint.org/mailinglist/Mailing-Lists/MiNT-List....

With EmuTOS, this meant that all the OS software was finally open source
(in beginning of this decade):
http://emutos.sourceforge.net/en/history.htm

Some people with extra time are still even creating new Atari compatible
hardware:
http://acp.atari.org/about.html

Or modeling old ones in VHDL:
http://www.experiment-s.de/en

And there are several emulators for them too, either intended as a
replacement new Atari machines (similar to what Amiga Forever does):
http://aranym.org/

Or just emulating the old machines as well as possible:
http://hatari.berlios.de/

...so that remaining demo coders can use it to do new Atari demos more
easily:
http://dhs.nu/

LPC: 25 years of X

Nerdbeard — Wed, 07 Oct 2009 15:21:56 +0000

Oh my, oh my. I ran W on MiNT, what seems like fifteen years ago. My poor 520STfm could not possibly host X, but W was a ton of fun. Thanks for reminding me about all that crazy stuff.

X: 25 years and still lacking vsync'ed double buffering

pphaneuf — Wed, 07 Oct 2009 04:47:13 +0000

I think the reason why there's no good vsync support in X is that you can't hook interrupts from user-space, and they didn't want to poll, because it would have made everything else suck.

Note that there's nothing in the X11 API that precludes using vsync to avoid tearing without exposing it in the API. What you need is just for a drawing command not to be in effect while the retrace is over the affected area.

X could implement its drawing so that this doesn't happen in the middle of one of its drawing commands, and you wouldn't get tearing. Now, you might not want a partially drawn image, even if it does so without any tearing. In that case, you can just do the double buffering yourself, by drawing into a pixmap instead of directly in the window, and XCopyArea the pixmap to the window when you're done (which is a single operation, so could be done without tearing).

The only thing that would need an extension for is throttling, so that you don't draw more than one image to your pixmap when only one copy can be made to the window. What you'd want is a XCopyArea that would send an event back to the client when it has been done. That can even support two displays with different update rates, you'd just get the event for different copies at a different rate, depending on where you put it.

X: 25 years and still lacking vsync'ed double buffering

cortana — Fri, 02 Oct 2009 23:09:49 +0000

Here's a picture illustrating the effects of tearing:

http://forum.i3d.net/attachments/technische-hulp-cod4/943...

LPC: 25 years of X

nix — Fri, 02 Oct 2009 21:10:33 +0000

Oops. I forgot the procedure for complaining about changes in xorg.conf
option semantics.

The right thing to do would have been to explode into conspiracy theories
in interminable threads on the xorg list about how the REAL problem with
AllowDeactivateGrabs was that a CONSPIRACY of EMACS users such as all the
X developers (ignoring the majority who use vi or edlin) had INTENTIONALLY
removed this feature with MALICE AFORETHOUGHT, knowing that the feature is
CRITICALLY useful when one is running dozens of VIRTUAL MACHINES under a
closed-source VM management tool on one's embedded TOASTER.

I'll try to remember this in future.

X: 25 years and still lacking vsync'ed double buffering

hrydgard — Fri, 02 Oct 2009 21:03:08 +0000

That's a new one - never heard of that problem, unless it's related to
"snow", which would happen if you changed the palette during parts of the
frame under various EGA and VGA graphics modes and has similar causes.

LPC Slides/Videos (including Keith's Keynote video)

hrydgard — Fri, 02 Oct 2009 21:00:38 +0000

Thanks for the links!

No, I didn't attend, but I'm really interested in the nice improvements that
are coming down the pipeline to Linux's video and audio systems, which both
have sadly long been messy and lagging far behind what's available on
competing platforms - from a pure desktop, not multi-user client/server,
perspective.

X: 25 years and still lacking vsync'ed double buffering

dion — Fri, 02 Oct 2009 18:26:59 +0000

That's a new definition for me.

It doesn't matter what it's called though, doing updates to the screen at any other time that during vsync looks like ass.

X: 25 years and still lacking vsync'ed double buffering

mjg59 — Fri, 02 Oct 2009 18:02:56 +0000

"if a LCD is connected via a VGA interface include the vertical retrace delay, ones connected via digital interfaces do not."

They do. A *lot* depends on having that interval available.

"having an image change halfway through an update from one frame to the next with no other distortion of the screen (and cleaned up on the next frame refresh) is a _very_ minor issue compared to loosing sync which scrambles the screen for a significant amount of time (several seconds on a LCD)"

The common case is watching videos or playing games, where it's not cleared up on the next frame refresh because another update has happened in the meantime. It manifests itself as a consistent discontinuity in the image. It's greatly irritating.

X: 25 years and still lacking vsync'ed double buffering

dlang — Fri, 02 Oct 2009 17:59:10 +0000

if a LCD is connected via a VGA interface include the vertical retrace delay, ones connected via digital interfaces do not.

having an image change halfway through an update from one frame to the next with no other distortion of the screen (and cleaned up on the next frame refresh) is a _very_ minor issue compared to loosing sync which scrambles the screen for a significant amount of time (several seconds on a LCD)

X: 25 years and still lacking vsync'ed double buffering

mjg59 — Fri, 02 Oct 2009 17:39:17 +0000

LCDs aren't (in the relevant cases) pixel addressable devices. The framebuffer is still scanned out at the vertical refresh rate and the entire image sent to the LCD each time - starting at the top left pixel and finishing at the bottom right. There's even an interval between the end of a frame and the beginning of the next one.

Whatever the original meaning of the word "tearing" as relating to video, its use to describe the effect caused by framebuffer updates not being synchronised with scanout and the associated discontinuity in the image is well established.

X: 25 years and still lacking vsync'ed double buffering

dlang — Fri, 02 Oct 2009 17:02:08 +0000

vertical retrace interval is an artifact of the CRT and the fact that it takes time to steer the electron beam from the bottom of the display back up to the top of the display.

on an LCD it takes no more time to go from the bottom of the display to the top of the display than it takes to go from the first row to the second row.

in any case, the cause of tearing was caused by disrupting the sync signals (most commonly the horizontal sync at the beginning of each line) causing the display to 'tear' horizontally across the screen. by waiting to update the video ram until the vertical retrace period (when the CRT isn't displaying anything anyway)you avoided causing this problem.

with dual-port ram or a digital feed to the display this problem just doesn't exist

X: 25 years and still lacking vsync'ed double buffering

hrydgard — Fri, 02 Oct 2009 07:49:52 +0000

LCD monitors absolutely do vertical retrace, it's just not as visible, but
tearing remains a problem. How else would the signal get to the display, did
you think there were individual wires from each cell of framebuffer memory
to each pixel on the display?

X: 25 years and still lacking vsync'ed double buffering

Tuxie — Fri, 02 Oct 2009 06:45:52 +0000

This is effectively fixed by enable triple buffering in xorg.conf.

Without triple buffering, playing videos with a similar but not exact multiple of the screen Hz (like 29.97 FPS video on a 60 Hz display) can cause problems. MPlayer can come to a situation where each frame is finished just after the vblank so it will stall waiting for vblank most of the time, leaving little time left to do actual decoding, resulting in very choppy playback. This is especially visible on low Hz modes like "24p" (23.976 Hz) and HD video. Enabling triple buffering solves this.

It doesn't however fix the problem with drifting audio/video sync when video/screen Hz only almost match. For that you need either hard frameskips or syncing audio to video with resampling or AC3/DTS packet dropping/duplication, which AFAIK only recent SVN snapshots of XBMC can do on Linux systems. MPlayer and stable XBMC sync video to audio.

For some reason (Nvidia driver bug?) though, triple buffering cause problems with Nvidia hardware decoding/rendering (VDPAU) so if you rely on VDPAU to do your video playback you will want to disable it.

It will also cause a display lag of one frame so you may want to disable it for fast paced FPS games.

LPC Slides/Videos (including Keith's Keynote video)

niv — Fri, 02 Oct 2009 03:10:19 +0000

Most of the slides are available on our LPC Program page already, and the videos of the keynotes (and some sessions) will be up there too as soon as we get them (hoping in a week or two). Please see our call for material and feedback on the LPC blog as well. If you were at LPC (or even if you weren't), you can send us feedback on the content of the sessions and the conferenceas a whole. We'd appreciate hearing from you!

LPC: 25 years of X

intgr — Thu, 01 Oct 2009 22:00:40 +0000

Greg Kroah-Hartman did a quick one for Xorg in the 2008 Linux Plumbers Conference keynote: http://video.google.com/videoplay?docid=3385088017824733336

LPC: 25 years of X

JLCdjinn — Thu, 01 Oct 2009 20:36:42 +0000

s/face/fact/, and I once again request comment editing. :)

LPC: 25 years of X

JLCdjinn — Thu, 01 Oct 2009 20:35:52 +0000

Why did "all innovation on X simply stop" when its maintenance was assigned to the X Consortium? Is that related to the face that with the BSD license, "every vendor took the X code and created its own, closed fork", or did something else happen to land X in a swamp?

X: 25 years and still lacking vsync'ed double buffering

dlang — Thu, 01 Oct 2009 20:32:45 +0000

actually, I thought that tearing referred to the problem that (especially on older, cheaper video cards) if you updated the screen while it was being drawn it corrupted the video output so that the screen sync failed. The better video cards used dual-ported ram that could be accessed by two chips at the same time so that it could be updated and read without causing tearing.

just displaying part of the old image and part of the new image is not the same thing.

X: 25 years and still lacking vsync'ed double buffering

dion — Thu, 01 Oct 2009 20:25:32 +0000

Well, tearing refers to the problem you see when someone updates the on-screen image while it's being sent to the screen, thus showing some of the old and the new frame for a while.

If all drawing to the screen happens to a back buffer and that buffer is only flipped into view during retrace then tearing cannot happen.

You are entirely correct that the entire rendering chain has to be synchronized and driven by the retrace, if you want the best possible result, but it would help a great deal if X could simply stay away from the on-screen buffer until there was a retrace.

Tearing is by far the most nasty artifact that comes from sloppy graphics work, but an application that jumps between full framerate and half framerate (say 70 and 35 Hz) looks almost as bad, so setting up a proper synchronized rendering chain would certainly be worth doing.

I don't think any of this would have to eat truck loads of memory, though, you'd certainly need to have a number (3 or more) frames buffered, but that's nothing compared to the memory on common graphics cards these days.

The buffering might not have to happen for the entire screen, you could easily have a single application (a video player, perhaps) that's the only thing that really needs to sync to vtrace and run at a fixed framerate to look good, that single app. could have a deep set of buffers, everything else could get by with the global tripple bufer.

X: 25 years and still lacking vsync'ed double buffering

oak — Thu, 01 Oct 2009 19:10:58 +0000

Well, I think vsynching the X screen is the trivial issue as that's only a
small piece of the tear-free graphics puzzle. You need to sync every
thing in this chain with each other: application / GUI toolkit-> app
window composite buffer -> composite manager -> X screen -> monitor.

Things could get more complicated to implement when some windows are using
OpenGL for updating the content (i.e. use something else than CPU to
update it), some use Xvideo, some different GUI toolkits. These should
then be suppored by different composite managers (or window manager if one
isn't using composite manager) one can be using. And somebody above
mentioned also xinerama...

At least it's going to eat truckloads of extra memory.

LPC: 25 years of X

marcH — Thu, 01 Oct 2009 14:53:35 +0000

> They just wrote new management wrappers, though; I'm not aware of any patches contributed to the actual NX code.

Last time I tried NX (before the Google contributions), the "actual" NX code was already running fine. But the existing "management wrappers" were a big pile of unreliable sh... ell scripts spoiling the whole thing.

LPC: 25 years of X

nix — Thu, 01 Oct 2009 09:54:18 +0000

Ah, great. The mailing list thread I read had people saying things more like "it is broken and there's no way to do it properly because it can sometimes cause crashes and inconsistent X server state, go away", which I thought rather peculiar because if a grab has gone wild and can't be broken the user is going to be shooting down the whole X server soon, inconsistent state or no.

But if it *is* possible to do it properly and it's coming back, excellent!

LPC: 25 years of X

ncm — Thu, 01 Oct 2009 02:17:13 +0000

Android doesn't run X, normally.

X: 25 years and still lacking vsync'ed double buffering

BenHutchings — Thu, 01 Oct 2009 01:52:04 +0000

No slides, but the notes are at http://dri.freedesktop.org/wiki/CompositeSwap

LPC: 25 years of X

oak — Wed, 30 Sep 2009 19:41:25 +0000

> Worse are dashed ellipses, which turn out to be intractable altogether.

These WWS doesn't implement. The lines can be patterned, but if I
remember correctly my code, the pattern is based on the window
co-ordinates (this way the patterns for overlapped elements would match).

Btw. If you test the code, the arc drawing can be a bit buggy, it doesn't
handle all the corner cases (I didn't anymore have that much time for WWS,
and there wasn't really any users for that feature :-)). I've understood
that this was fixed in the Microwindows/Nano-X adaption of the code. They
needed it for their Xlib emulation, so they have tested it properly.

Arc endpoint calculations are done in the client library so that server
doesn't need to do any floating point calculations (a bit similar strategy
to Xft in pushing work to clients that cause the work).

LPC: 25 years of X

daniels — Wed, 30 Sep 2009 19:30:31 +0000

Yeah, sorry about AllowDeactivateGrabs. It was broken, so we ripped it out as the first step along the way to actually doing it properly. It will be back. :)

X: 25 years and still lacking vsync'ed double buffering

hrydgard — Wed, 30 Sep 2009 18:44:04 +0000

That's interesting - any idea where to get the slides from that (and other)
talk(s) from the conference?

Sorry for the almost content-less comment.

X: 25 years and still lacking vsync'ed double buffering

dgm — Wed, 30 Sep 2009 15:39:24 +0000

Well, if I understood it right, XGL was about implementing X over OpenGL. What dion suggested instead was bypassing X, and make toolkits talk directly with the OpenGL driver. It has been suggested many times in GTK, as explained in this article, that also enumerates most of the reason why it's not a good idea: http://blogs.gnome.org/timj/2007/07/17/17072007-opengl-fo...

Also, network transparency and multiple displays make synchronizing with the vertical retrace a complex matter. What's more, current LCD monitors and other display technologies like e-paper do not do any vertical retrace (AFAIK).

In my opinion, what would be useful is some means to avoid unnecessary work in applications. What's the point of repainting the screen at 1200 fps when only 60 can be displayed due to limitations in the display? Wouldn't it be better to save all that wasted power?

LPC: 25 years of X

dgm — Wed, 30 Sep 2009 14:57:50 +0000

For a closed ellipses both descriptions should be geometrically equivalent, shouldn't they? What I'm missing?

LPC: 25 years of X

marcH — Wed, 30 Sep 2009 10:33:23 +0000

> When it comes to X, it's always with Keith's photo! Good tradition :)

I this a tradition to make the article more graphic?

LPC: 25 years of X

sgros — Tue, 29 Sep 2009 15:30:40 +0000

What about performing analysis of X's git logs like the analysis done for kernel. It would be interesting to see in what shape is X who's working on it.

LPC: 25 years of X

PO8 — Tue, 29 Sep 2009 09:13:20 +0000

Something was lost in translation, I think. Wide ellipses in X aren't specified as being drawn with a circular pen. Instead, they are specified as being drawn by moving a linear pen along the ellipse while holding it perpendicular to the ellipse. This turns out to be a really bad specification; the ellipses have these funny "hooks" and it really does require a nasty high-order polynomial to describe the inner and outer hull of the wide ellipse to the exact pixelization X requires. Worse are dashed ellipses, which turn out to be intractable altogether.

X: 25 years and still lacking vsync'ed double buffering

BenHutchings — Tue, 29 Sep 2009 01:24:33 +0000

This was actually covered in another talk on the Graphics track. Jim Gettys, also in attendance, pointed out that there has been an XSync extension for over 20 years, though XFree86/Xorg doesn't implement it. (Apparently this was introduced to support video-conferencing before there was more extensive video acceleration exposed through the XVideo extension.)

LPC: 25 years of X

Trelane — Tue, 29 Sep 2009 00:23:34 +0000

"which was release in 1986"

I think you need a "d" there. :)