Slashdot Mirror
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.
For a free exhibit hall pass use the promo code 'free'.
For 50% off a full access pass use the code 'sctek'
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)
We returned a new 19" monitor the other day because it was native 1600x1200. The text was unreadable at that resolution and lower resolutions simply looked like crap. We replaced it with a 1280x1024 bit but that is still on the small side.
The last time that this was brought up on slashdot, most of the arrogant jerks tried to point out that you can "simply adjust the font size in the control panel". This doesn't work for anyone who has tried it.
Longhorn will take a big step forward in this area. They will be rendering the window system and applying it as a texture so that the DPI of the monitor is irrelevant. X will be light years behind if it doesn't do this first.
Life is the leading cause of death in America.
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.
"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 ?
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!
Fortunately the X protocol can be extended without being replaced. OpenGL (GLX actually), Xrender, XVideo and the XSHM (the shared memory extension) are all examples of extensions that have been added without breaking old apps. Parts of X may be crusty, but overall it is pretty well designed.
XFree86 has done even better than not breaking the protocol. IIRC they have been *binary* compatible for Xlib for over 4 years.
You don't seem to understand the problem the way it was meant. I have a big monitor, I like to run at high resolution, but text is TINY, so I make the fonts bigger, but then everything is out-of-whack in terms of widget sizes and images.
What we're talking about is a VECTOR-based display, so 'increasing the size' won't make it any less readable. In a vector-based system EVERYTHING gets scaled up, you could run the big monitor at 1600x1200 or 512x384 and the elements on the screen would be the same actual size (meaured by a ruler) but the higher-res monitor would just look a hell of a lot better.
Now there ARE some issues that need to get worked out for this, a web browser, for example has to be prepared to have a bitmap GIF 'blown up', and it has to be done well enough to look decent but not take too much CPU power.
NEXT had this, Aqua has the underpinning of it, I think GNUStep is coming along with it, Longhorn is going to have it. I don't see the XFree86 folks picking this up, I think the toolkit folks and KDE/GNOME will have to implement it themselves because the XFree folks are really conservative.
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
How is this different from backing store?
Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
...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?