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."
its about time someone does some decent work on the actuyal framework of the xserver, because right now, most limitations are not due to the window manager, rather the server.
cool! decent opengl integration will make all those little flashy transitons and funny shaped windows that mac users have a snap to implement! x finally becomes less about boring rectangles, and becomes truly fun to hack ;)
Lets hope this gets support from enough different groups to make it a standard.
And then we can start hoping for something similar to the venerable pipe, but allowing easy use for graphical / media components! (ok i'll go back to dreaming)
Assuming xlib isn't statically linked, I don't think there'll be too much of a problem. I'd even venture a guess that simpler applications wouldn't be affected at all.
tasks(723) drafts(105) languages(484) examples(29106)
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!
Combination - fun iPhone puzzling
Let's summarize the discussion that this is going to trigger:
Whine 1: X is slow and bloated we need a replacement.
Response 1: The XFree86 implementation may be slow and bloated and not the protocol.
Response 2: Come up with something better and we'll talk.
Whine 2: Who uses the remote display capability of X anyway?
Response 1: On local displays X uses shared memory and is fast enough.
Response 2: If 5% of the users need the feature it should be retained.
This seems to be a band aid solution and complex as well. With OpenGL being so prevalent why not create an X replacement entirely upon it?
an ill wind that blows no good
...was to be able to cut and paste between applications. A unified API for a clipboard system that uses a unified set of keys to cut and paste.
Alpha blending should be miles and miles behind the development of a window system that actually works.
But, this looks to be more typical X development. No brake pedal, but you can shift gears via the steering wheel, the stereo, or a series of buttons on the sunroof; it has 539 airbags, each requiring a different pressure to go off, and there's a seatbelt interface for every previous seatbelt in existance. Plus it has the most efficient 46 horse power engine ever made, even though opening the glove compartment causes it to stall, or at least backfire.
~Wx
sig?
Do you expect your grandma to open her box and install a new graphics card?
No more than I would expect my grandma to update her X Windows library to incorporate new buffering extensions.