New X Proposal on Freedesktop.org

Bytal writes "Havoc Pennington (of Red Hat and GNOME fame) seems to have a very interesting entry in his blog on the development of a new extension to the venerable X server going on at freedesktop.org. More specifically it seems to provide for most things that people have clamoring for (alpha blending, flicker-free window compositing and switching, as well as even OpenGL integration) without altering the existing X protocol too much."

Comments

FreeDesktop.org at SCALE 2x

[irabinovitch]

Seth Nickell will be speaking about the freedesktop.org project and his work with GNOME.org at the Southern California Linux Expo on November 22, 2003. SCALE 2003 will be held at the Los Angeles Convention Center. More information is available on their website at http://www.socallinuxexpo.org

For a free exhibit hall pass use the promo code 'free'.
For 50% off a full access pass use the code 'sctek'

Good idea, but not new

[Chris_Jefferson]

The main principle here seems simply to be for the X-server to store each window, wether it be visable or not. At the moment if you stack windows on top of each other the X-server forgets what is on the covered up bits, and when the window becomes visable again it is redrawn. This was a good idea back when memory was scarce, because storing X full screen applications could take X*screensize memory. However today with more memory, we can store all those windows without forcing a redraw.

This is long overdue in X, and also as stated makes things like alpha blending, and Mac OS-X style openGL window-dragging acceleration much more trivial, and also for those who like network transparency, won't require resending windows each time they become visable (although adds the new problem that unless you are careful you could end up spending lots of time sending updates to non-visable windows). It is of course nessasary to allow some chucking of hidden windows (because full screen 32-bit images still take up quite a lot of room), but overall its a good plan!

Re:Good idea, but not new

[Anonymous Coward]

This is long overdue in X

Uh, this idea is called "backing store" and it's been around since, I believe, X11R4. I'm not sure what this proposal does that's new, other than offer new uses for it.

Given the current bloat of GTK and Gnome when trying to run remotely (even over 100Mbit), backing store is a good thing. When an application lets you turn it on. Which GTK doesn't. Heck, I've even seen a GTK developer claim "X doesn't have any backing store concept." Geez, people, learn your existing technology!

Re:Good idea, but not new

[otaylor]

Likely the GTK+ developer was me. I certainly didn't say that X has no concept of backing store. I may well have indicated that the current X implementation of backing store quite typically does more harm than good. For instance, under some circumstances, X will store arbitrarily large amounts of pixel data *outside* of the windows bounds in the windows backing store. (Having traced through the X server code to figure out why this was happening some years ago, I can authoritatively say that X does have a concept of backing store.)

Keith's new extension is quite different from traditional X backing store; the obvious difference is the ability to control how the windows are composited to the screen. But there are other differences; the server, for instance, uses only a single backing store buffer for the entire toplevel window, instead of one for each subwindow.

Extra Memory Usage

[mickwd]

"The server stores a tree of windows as it does now. However, unlike today, it keeps the full contents of each mapped window in memory at all times."

What are the memory implications of this ?

With many people using resolutions of 1280x1024 or 1600x1200 in 24-bit or 32-bit colour, dual-displays and multiple desktops becoming more common, this could chew up a lot of RAM.

A single, maximised window at 1600x1200/32-bit is going to use 7.5MB, even if it's just a terminal window. I can quite easily have 10 windows open at one time, especially when web browsing (OK, not all maximised, but not all small, either). There goes 75MB of RAM, just for the screen display (let alone the extra memory X uses for pixmaps, etc). If it's constantly being accessed in order to update the display, it won't be easily paged out to disk, either.

Things like tabbed browsers and terminal programs help quite a bit (assuming that the contents of each tab won't be stored in RAM - or will they ?). But not everyone likes using them.

Would someone with more knowledge about the current workings of X care to comment ?

Re:Extra Memory Usage

[IamTheRealMike]

I am not an expert but I'll answer as well as I can.

What are the memory implications of this ?

The reason keithp is going to be buffering each node in the window tree is for memory reasons - buffering entire toplevel windows is far too expensive. It involves two extensions, aXe and XDAMAGE to work correctly. I believe XDAMAGE is partly useful for reducing the work needed to implement eyecandy effects, but it's all new to me too so I'm prolly wrong.

Secondly, MacOS X gets around the memory requirements partly through heavy use of video RAM and partly through compressing and decompressing toplevel windows on the fly (as far as I know). I wouldn't be surprised if the new X team take a similar route.

Finally, I don't think OpenGL will feature in this. OpenGL is a neat 3D API but not so great at 2D work - we seem to be heading towards using XRender as our low-level 2D API with Cairo providing a Quartz style drawing system on top. That doesn't imply speed loss - both OpenGL and XRender are abstractions over the hardware acceleration engines of the card, so there's no reason why XRender based apps could not get the sort of speeds we associate with 3D HW accel (even if today it doesn't reach those speeds). The advantage of going the Xrender route is that it's much easier to mix and match the old style and new style rendering (note how OpenGL requires you to set it up for a particular rect but XRender can just be used as a standard drawing op).

Like I said, no expert, keithp is the canonical source for this, but that's what I've gathered from reading and listening.

Is there a new X logo out as well?

[Zanthany]

I seem to be seeing a new X logo as well from the slashdot page:

slashdot.jpg

It's so simple and plain. It just might work!