LPC: 25 years of X
This article brought to you by LWN subscribers Subscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible. |
The X Window System quietly hit its 25th anniversary back in June; it is, undoubtedly, one of the oldest and most successful free software projects in existence. Keith Packard has been working with X for most of that time; at the Linux Plumbers Conference in Portland he used his keynote address to look at the highlights (and lowlights) of those 25 years and some of the lessons that have been learned.
The version of X we know today is X11. There were nine predecessor versions (one got skipped), but the first version to escape widely was X10, which was released in 1986. Companies were shipping it, and the vendors which formed the X Consortium were starting to think that the job was done, but the X developers successfully pleaded for the opportunity to make one more "small" set of revisions to the X protocol. The result was X11 - a complete reworking of the whole system - which was released on September 15, 1987; it is still running today.
There was a wealth of new ideas in X11, some of which made more sense than others. One of those ideas was the notion of an external window manager. In X, the window manager is just another process working with the same API. This approach helped to create a consistent API across windows, and it also made it possible to manage broken (non-responding) applications in a way that some other systems still can't do. On the other hand, the external window manager created a lot of on-screen flashing - a problem which still pops up today - and it does not work entirely well with modern compositing techniques, getting in the way of the page-flipping operations needed to make things fast.
The use of selections for cut-and-paste operations was another early X11 innovation. With selections, the source of selected data advertises its availability, and the destination requests it in the desired format. This mechanism allows data to be selected and moved between applications in almost any format. Unfortunately, the "cut buffer" concept was left in, so applications had to support both modes; the fact that Emacs was not updated to use selections for a very long time did not help. The existence of multiple selections created interoperability problems between applications. On the other hand, the selection mechanism proved to be a very nice foundation for drag-and-drop interfaces, and it handled the transition to Unicode easily.
Input has been the source of a number of problems. The requirement that applications specify which events they want made sense when the focus was on trying to make the best use of a network connection, but it led to some interesting behavioral changes depending on how applications selected their events. X was meant to be a policy-free system, but, in retrospect, the rules for event delivery were a significant amount of policy wired into the lowest levels of the system.
"Grabs," where an application can request exclusive delivery of specific events, were a case in point. "Passive grabs" allow window managers to bind to specific keys (think alt-middle to resize a window), but that required a non-intuitive "parent window gets it first" policy when these grabs are in use. "Synchronous grabs" were worse. They were intended to help create responsive interfaces in the face of slow networks and slow applications; clicking on a window and typing there will do the right thing, even if the system is slow to respond to the click and direct keyboard focus correctly. It was a complicated system, hard to program to, harder to test, and it required potentially infinite event storage in the X server. And it's really unnecessary; no applications use it now. This "feature" is getting in the way of more useful features, like event redirection; it may eventually have to be removed even at the cost of breaking the X11 protocol.
Text input was not without problems of its own; X went to considerable effort to describe what was written on every key, and required applications to deal with details like keyboard maps and modifier keys. It worked reasonably well for English-language input, but poorly indeed for Asian languages. The addition of the XIM internationalization layer did not really help; it was all shoved into the Xlib library and required that applications be rewritten. It also forced the installation of a large set of core fonts, despite the fact that most of them would never be used.
Text output was "an even bigger disaster." It required that fonts be resident in the server; applications then needed to pull down large sets of font metrics to start up. That was bad enough, but generating the font metrics required the server to actually rasterize all of the glyphs - not fun when dealing with large Asian fonts. Adding fonts to the system was an exercise in pain, and Unicode "never happened" in this subsystem. In retrospect, Keith says, there was an obvious warning in the fact that neither FrameMaker nor Xdvi - the two applications trying to do serious text output at that time - used the core fonts mechanism.
This warning might have been heeded by moving font handling into clients (as eventually happened), but what was done at that time, instead, was to layer on a whole set of new kludges. Font servers were introduced to save space and make addition of fonts easier. The XLFD (X logical font description) mechanism inflicted font names like:
-adobe-courier-medium-r-normal--14-100-100-100-m-90-iso8859-1
on the world without making life easier for anybody. The compound text mechanism brought things forward to iso-2022, but couldn't handle Unicode - and, once again, it required rewriting applications.
The X drawing model had amusing problems of its own. It was meant to be "PostScript lite," but, to get there, it dispensed with small concepts like paths, splines, and transforms, and it required the use of circular pens. So there really wasn't much of PostScript left. The model required precise pixelization, except when zero-width "thin" lines were used - but all applications ended up using thin lines. Precise pixelization was a nice concept, and it was easily tested, but it was painfully slow in practice.
The use of circular pens was the source of more pain; the idea was taken from the PostScript "Red Book," but, by then, the PostScript folks had already figured out that they were hard to work with and had kludged around the problem. A line drawn with a circular pen, in the absence of antialiasing, tends to vary in width - it looks blobby. The generation of these lines also required the calculation of square roots in the server, which was not the way to get the best performance. Even so, people had figured out how to do circular pens right, but nobody in the X team knew about that work, so X did not benefit from it.
Rather than provide splines, the X11 protocol allowed for the drawing of ellipses. But there was a catch: ellipses had to be aligned with the X or Y axis, no diagonal ellipses allowed. There was a reason for this: there was a rumor circulating in those days that the drawing of non-axis-aligned ellipses involved a patented algorithm, and, for all of the usual reasons, nobody wanted to go and actually look it up. It turns out that the method had been published in 1967, so any patent which might have existed would have been expired. But nobody knew that because nobody was willing to take the risks involved with researching the alleged patent; even in the 1980's, software patents were creating problems.
As an added bonus, the combination of ellipses and circular pens requires the evaluation of quartic equations. Doing that job properly requires the use of 128-bit arithmetic; 64-bit floating-point numbers were not up to the job.
Color management was bolted on at a late date; it, too, was shoved into the "thin and light" Xlib layer. It provided lots of nice primitives for dealing with colors in the CIE color space, despite the fact that users generally prefer to identify colors with names like "red." So nobody ever used the color space features. And the "color management" code only worked with X; there was no provision for matching colors in output to graphic metafiles or printed output. X color management was never a big hit.
[PULL QUOTE: All of these mistakes notwithstanding, one should not overlook the success of X as free software. END QUOTE] All of these mistakes notwithstanding, one should not overlook the success of X as free software. X predates version 1 of the GPL by some five years. Once the GPL came out, Richard Stallman was a regular visitor to the X Consortium's offices; he would ask, in that persistent way he has, for X to change licenses. That was not an option, though; the X Consortium was supported by a group of corporations which was entirely happy with the MIT license. But in retrospect, Keith says, "Richard was right."
X was an industry-supported project, open to "anybody but Sun." Sun's domination of the workstation market at that time was daunting to vendors; they thought that, if they could displace SunView with an industry-standard alternative, they would have an easier time breaking into that market. Jim Gettys sold this idea, nearly single-handedly, to Digital Equipment Corporation; it is, arguably, the first attempt to take over an existing market with free software. It worked: those vendors destroyed Sun's lock on the market - and, perhaps, Keith noted, the Unix workstation market as a whole.
There were problems, needless to say. The MIT license discourages sharing of code, so every vendor took the X code and created its own, closed fork. No patches ever came back to the free version of X from those vendors. Beyond that, while the implementation of X11 was done mainly at DEC, the maintenance of the code was assigned to the X Consortium at MIT. At that point, Keith said, all innovation on X simply stopped. Projects which came out of the X Consortium in these days were invariably absolute failures: XIE, PEX, XIM, XCMS, etc. There began the long, dark period in which X essentially stagnated.
X is no longer stagnant; it is being heavily developed under freedesktop.org. As X has come back to life, its developers have had to do a massive amount of code cleanup. Keith has figured out a fail-safe method for the removal of cruft from an old code base. The steps, he said, are these:
- Publish a protocol specification and promise that there will be
long-term support.
- Realize failure.
- "Accidentally" break things in the code.
- Let a few years go by, and note that nobody has complained about the
broken features.
- Remove the code since it is obviously not being used.
Under this model, the XCMS subsystem was broken for five years without any complaints. The DGA code has recently been seen to have been broken for as long. The technique works, so Keith encouraged the audience to "go forth and introduce bugs."
The important conclusion, though, is that, after 25 years, X survives and
is going strong. It is still able to support 20-year-old applications.
There are few free software projects which can make that sort of claim.
For all its glitches, kludges, and problems, the X Window System is a clear
success.
(Log in to post comments)
LPC: 25 years of X
Posted Sep 27, 2009 20:20 UTC (Sun) by mtaht (guest, #11087) [Link]
LPC: 25 years of X
Posted Sep 28, 2009 13:09 UTC (Mon) by proski (subscriber, #104) [Link]
Yes, but it was lost during debugging :-)
LPC: 25 years of X
Posted Sep 27, 2009 20:28 UTC (Sun) by ikm (subscriber, #493) [Link]
LPC: 25 years of X
Posted Sep 30, 2009 10:33 UTC (Wed) by marcH (subscriber, #57642) [Link]
I this a tradition to make the article more graphic?
LPC: 25 years of X
Posted Sep 27, 2009 21:17 UTC (Sun) by oak (guest, #2786) [Link]
requires the evaluation of quartic equations.
Nonsense. You can get the closest and furthest points on a circle on an
ellipse arc with just multiplication and addion and do the drawing based
on that. For an example, see the "generic_circle.c" file in
http://koti.mbnet.fi/tammat/src/wws_1.4.5.tar.gz
(X lets one to specify ellipses with width and height, W only by radius.
To get the W code to handle also half-pixel radiuses, one would need to
shift the values by one bit. WWS code was later adopted also for
MicroWindows / Nano-X window system.)
LPC: 25 years of X
Posted Sep 29, 2009 9:13 UTC (Tue) by PO8 (guest, #41661) [Link]
LPC: 25 years of X
Posted Sep 30, 2009 14:57 UTC (Wed) by dgm (subscriber, #49227) [Link]
LPC: 25 years of X
Posted Sep 30, 2009 19:41 UTC (Wed) by oak (guest, #2786) [Link]
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
Posted Oct 7, 2009 15:21 UTC (Wed) by Nerdbeard (guest, #61214) [Link]
LPC: 25 years of X
Posted Oct 7, 2009 20:05 UTC (Wed) by oak (guest, #2786) [Link]
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
Posted Sep 27, 2009 22:38 UTC (Sun) by nix (subscriber, #2304) [Link]
mmap()ing something in the server and handing the pointer to the client!
That could never ever have worked, and as it's a designed-in feature I
can't see how it could have been added at a later date.
As long as DGA works to flip to fullscreen I don't think anyone will miss
it. (And as for PEX, EWWWWW. Nice idea, appalling implementation. I
cheered when that was dropped.)
(But some useful features *have* been dropped. AllowDeactivateGrabs in
particular was a lifesaver on more than one occasion. I emphasise 'was'.
Just last week I had to kill X when a wild grab stole it from me...)
LPC: 25 years of X
Posted Sep 30, 2009 19:30 UTC (Wed) by daniels (subscriber, #16193) [Link]
LPC: 25 years of X
Posted Oct 1, 2009 9:54 UTC (Thu) by nix (subscriber, #2304) [Link]
But if it *is* possible to do it properly and it's coming back, excellent!
LPC: 25 years of X
Posted Oct 2, 2009 21:10 UTC (Fri) by nix (subscriber, #2304) [Link]
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.
Error analysis
Posted Sep 28, 2009 6:30 UTC (Mon) by man_ls (guest, #15091) [Link]
Excellent article! Unlike more popular publications most of the readership don't need a marketing blob saying how successful X has been, since we have actually seen how it scales from HPC clusters to pocket devices. OTOH the focus on past errors is a great way to see how it could have been done better -- and learn a few lessons in the way. This is what tells apart good from bad engineers -- the apparent focus on the negative, which is just a way of avoiding such pitfalls in the future. (If you will allow for a pedantic plug, Petroski's "Design Paradigms" presents a few examples from other branches of engineering.)
LPC: 25 years of X
Posted Sep 28, 2009 8:18 UTC (Mon) by pranith (subscriber, #53092) [Link]
LPC: 25 years of X
Posted Sep 28, 2009 14:21 UTC (Mon) by raven667 (subscriber, #5198) [Link]
improvements for high latency links. IIRC Google put some effort into the open-source NX software
because they use it a bunch internally.
LPC: 25 years of X
Posted Sep 28, 2009 21:01 UTC (Mon) by njs (guest, #40338) [Link]
LPC: 25 years of X
Posted Oct 1, 2009 14:53 UTC (Thu) by marcH (subscriber, #57642) [Link]
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
Posted Oct 1, 2009 2:17 UTC (Thu) by ncm (guest, #165) [Link]
X: 25 years and still lacking vsync'ed double buffering
Posted Sep 28, 2009 11:20 UTC (Mon) by dion (guest, #2764) [Link]
Way back when I started dabbling in graphics with DOS and VGA the learning curve was something like this:
1) Switch to graphics mode (int 0x13)
2) Putpixel (mess about in memory around 0xA0000)
3) Set pallette (port 0x3C8 & 0x3C9)
4) Draw in an off screen buffer to make the animation look good.
5) Sync to vtrace before copying the buffer to screen to avoid tearing.
6) Start doing useful work.
Now, true color displays has dispensed with #3, but #5 is still impossible to do with X and it's really sad because that's the main reason video and animations SUCK on X.
I realize that something like this DOS code would never fly on a multitasking system:
void vsync() {
/* wait until any previous retrace has ended */
do { } while (inportb(0x3DA) & 8);
/* wait until a new retrace has just begun */
do { } while (!(inportb(0x3DA) & 8));
}
... but come on! It has to be possible to do smooth full screen graphics, even with the added complexities of multitasking.
No application should ever run any other framerate than the 60-80 FPS that the display runs at, because if it does then it looks like ass, even if you do get to do proper double or tripple buffering that's synchronized to vsync.
I'm guessing the difficulty is that to know if the display is ready for a new frame you need support for the retrace interrupt and as nobody who writes drivers for X or X developers seem to care about tearing and smooth animations that little thing never gets implemented.
X: 25 years and still lacking vsync'ed double buffering
Posted Sep 28, 2009 12:31 UTC (Mon) by jdahlin (subscriber, #14990) [Link]
X: 25 years and still lacking vsync'ed double buffering
Posted Sep 28, 2009 14:56 UTC (Mon) by drag (guest, #31333) [Link]
driver model goes into non-broke mode.
That is when we get away from X having it's own particular set of video
drivers and having multiple drivers trying to drive the same display and the
same hardware then a lot of the very hard issues like this one should be much
easier to fix. (and worth fixing)
No more X DDX, Gallium ftw.
X: 25 years and still lacking vsync'ed double buffering
Posted Sep 28, 2009 13:25 UTC (Mon) by mjthayer (guest, #39183) [Link]
X: 25 years and still lacking vsync'ed double buffering
Posted Sep 28, 2009 14:11 UTC (Mon) by cortana (subscriber, #24596) [Link]
If I have two TFTs, will they both read from video memory at the same time?
What about two displays running at different rates?
Of course, this shouldn't mean that the common case of a single monitor is affected by these
problems. At least you can use OpenGL to wait for a vertical retrace (modulo problems on
old/unsupported hardware)...
X: 25 years and still lacking vsync'ed double buffering
Posted Sep 28, 2009 17:26 UTC (Mon) by dion (guest, #2764) [Link]
I guess every display should have its own vsynced double or triple buffer and the clients that care (most don't) should be able to get a maximum of one call-back per frame to do rendering for the next frame.
If the displays have different update rates and the window spans both displays, then I guess you're SOL:)
X: 25 years and still lacking vsync'ed double buffering
Posted Sep 28, 2009 18:01 UTC (Mon) by jzbiciak (guest, #5246) [Link]
If you want the same performance as triple buffering has on a single display (ie. the renderer is never blocked by vsync), for a window straddling N displays you would need N+2 buffers. With that, you can achieve the same non-blocking performance with an arbitrary number of displays.
On a flip, the application lets X know that the buffer just completed is the "most recent" and X can switch to an undisplayed buffer. Since there are N+1 buffers other than the one just completed, there is guaranteed to be at least one available buffer.
When each of the N displays reaches its vertical retrace, it pulls the "most recent" buffer at the time of its vertical retrace for the portion of the window covering that display. In the worst case (ie. a very fast application with an absurdly high frame rate displaying on N displays whose refresh rates are effectively relatively prime to each other, which could happen if they're all driven from separate crystals), all N displays could in fact be displaying their portion from different source frames. But, you won't get any shearing within each display.
You can decrease the buffering from there, sliding down a continuum of likelihood to block the application. The minimum buffering case is still the double buffer, but you have to wait for all displays to hit vertical retrace before the application can resume. Between 2 and N+2, you can have varying levels of "likelihood to block" while the application waits for at least one buffer to be undisplayed. Chances are, even with a largish N (such as, perhaps, a 25 display system arranged as a 5x5, with nominally the same refresh rate but driven from different crystals), performance shouldn't be too bad with as few as 4 buffers, since the displays are all flipping at about the same rate, particularly if your rendering rate isn't dramatically faster than your refresh rate.
X: 25 years and still lacking vsync'ed double buffering
Posted Oct 7, 2009 4:47 UTC (Wed) by pphaneuf (guest, #23480) [Link]
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
Posted Sep 28, 2009 19:14 UTC (Mon) by alankila (guest, #47141) [Link]
sync. Since there are only two buffers in doublebuffering, it follows that GLSwapBuffers() must sleep
until the swap is possible. Looking at the wider topic: perhaps it would be better to forget about X
and instead rewrite toolkits on top of OpenGL and then have OpenGL server instead of X server...
X: 25 years and still lacking vsync'ed double buffering
Posted Sep 28, 2009 20:54 UTC (Mon) by drag (guest, #31333) [Link]
Rewrite everything to run on OpenGL and then use OpenGL drivers to drive everything.
That effort is what lead to Kernel-Mode-Setting (OpenGL has no API for display control) and proper in-Kernel memory management. (having lots of applications open will use more video RAM then there is video RAM at one point or another).
Of course driving 2D displays on OpenGL is a huge pain in the ass. So that is why we have Gallium were you have 1 driver to drive multiple APIs.
API State Tracker --> Gallium Winsys --> DRI2 --> Linux-DRM --> Hardware
Instead of:
EXA/XAA/Xv --> X DDX --> Hardware
+
OpenGL --> DRI --> Linux-DRM --> Hardware
+
Codec decoding accel --> NULL
+
OpenVR --> NULL
+
OpenCL --> NULL
etc etc.
Anyways this is a better design since the world has moved on from OpenGL acceleration to much more general purpose GPUs with programmable shading languages and other things. This is leading to a full-featured GPGPUs which we will see in a year or two. This is were the GPU is just a co-processor of sorts and 'video acceleration' is just software that is compiled/designed/optimized to use the coprocessor as well as the GPU.
X: 25 years and still lacking vsync'ed double buffering
Posted Sep 28, 2009 20:56 UTC (Mon) by drag (guest, #31333) [Link]
not "coprocessor as well as the GPU"
but: GPU coprocessor as well as the CPU.
X: 25 years and still lacking vsync'ed double buffering
Posted Sep 30, 2009 15:39 UTC (Wed) by dgm (subscriber, #49227) [Link]
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?
X: 25 years and still lacking vsync'ed double buffering
Posted Oct 2, 2009 7:49 UTC (Fri) by hrydgard (guest, #54085) [Link]
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
Posted Oct 2, 2009 17:02 UTC (Fri) by dlang (guest, #313) [Link]
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
Posted Oct 2, 2009 17:39 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
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
Posted Oct 2, 2009 17:59 UTC (Fri) by dlang (guest, #313) [Link]
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
Posted Oct 2, 2009 18:02 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
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
Posted Oct 11, 2009 22:24 UTC (Sun) by Ross (guest, #4065) [Link]
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
Posted Oct 11, 2009 22:18 UTC (Sun) by Ross (guest, #4065) [Link]
X: 25 years and still lacking vsync'ed double buffering
Posted Oct 2, 2009 6:45 UTC (Fri) by Tuxie (guest, #47191) [Link]
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.
X: 25 years and still lacking vsync'ed double buffering
Posted Oct 8, 2009 7:52 UTC (Thu) by kragil (guest, #34373) [Link]
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)
X: 25 years and still lacking vsync'ed double buffering
Posted Sep 29, 2009 1:24 UTC (Tue) by BenHutchings (subscriber, #37955) [Link]
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.)
X: 25 years and still lacking vsync'ed double buffering
Posted Sep 30, 2009 18:44 UTC (Wed) by hrydgard (guest, #54085) [Link]
talk(s) from the conference?
Sorry for the almost content-less comment.
X: 25 years and still lacking vsync'ed double buffering
Posted Oct 1, 2009 1:52 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]
LPC Slides/Videos (including Keith's Keynote video)
Posted Oct 2, 2009 3:10 UTC (Fri) by niv (guest, #8656) [Link]
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 Slides/Videos (including Keith's Keynote video)
Posted Oct 2, 2009 21:00 UTC (Fri) by hrydgard (guest, #54085) [Link]
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
Posted Oct 1, 2009 19:10 UTC (Thu) by oak (guest, #2786) [Link]
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.
X: 25 years and still lacking vsync'ed double buffering
Posted Oct 1, 2009 20:25 UTC (Thu) by dion (guest, #2764) [Link]
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
Posted Oct 1, 2009 20:32 UTC (Thu) by dlang (guest, #313) [Link]
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
Posted Oct 2, 2009 18:26 UTC (Fri) by dion (guest, #2764) [Link]
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
Posted Oct 2, 2009 21:03 UTC (Fri) by hrydgard (guest, #54085) [Link]
"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.
X: 25 years and still lacking vsync'ed double buffering
Posted Oct 2, 2009 23:09 UTC (Fri) by cortana (subscriber, #24596) [Link]
http://forum.i3d.net/attachments/technische-hulp-cod4/943...
X: 25 years and still lacking vsync'ed double buffering
Posted Oct 11, 2009 22:09 UTC (Sun) by Ross (guest, #4065) [Link]
LPC: 25 years of X
Posted Sep 28, 2009 11:25 UTC (Mon) by bpearlmutter (subscriber, #14693) [Link]
Get used to it
We are desperate
Get used to it"
-- X
(The window system or the rock band? You decide.)
LPC: 25 years of X
Posted Sep 28, 2009 18:03 UTC (Mon) by ikm (subscriber, #493) [Link]
Under pretty much the same model, the RECORD extension has been broken for more than 9 months now. Do I need to say this sucks? ;)
LPC: 25 years of X
Posted Sep 28, 2009 23:03 UTC (Mon) by Velmont (guest, #46433) [Link]
LPC: 25 years of X
Posted Sep 28, 2009 23:59 UTC (Mon) by whot (subscriber, #50317) [Link]
LPC: 25 years of X
Posted Sep 29, 2009 0:23 UTC (Tue) by Trelane (subscriber, #56877) [Link]
I think you need a "d" there. :)
LPC: 25 years of X
Posted Sep 29, 2009 15:30 UTC (Tue) by sgros (guest, #36440) [Link]
LPC: 25 years of X
Posted Oct 1, 2009 22:00 UTC (Thu) by intgr (subscriber, #39733) [Link]
LPC: 25 years of X
Posted Oct 1, 2009 20:35 UTC (Thu) by JLCdjinn (guest, #1905) [Link]
LPC: 25 years of X
Posted Oct 1, 2009 20:36 UTC (Thu) by JLCdjinn (guest, #1905) [Link]
Synchronous grabs
Posted Oct 11, 2009 23:01 UTC (Sun) by Ross (guest, #4065) [Link]
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).