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."
For a free exhibit hall pass use the promo code 'free'.
For 50% off a full access pass use the code 'sctek'
"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 ?
Sorry mate, you're wrong. When I change resolution with my XFree86 the fonts stay the same size. The font sizes are calculated based on the dimensions of the monitor. If your fonts were unreadable you had configured something wrong (your distro had configured something wrong, whatever). In this case Windows has been light years behind X for a long time.
However widgets etc. are not generally vector based and thus can look tiny (esp. @ 1600x1200), in this region Longhorn could jump ahead of most free software you use with X. However, all this needs is the toolkit people (GTK, Qt, etc.) to make their toolkits vector based and this will cease to be a problem.
I don't think you deserved your mod points personally.
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!
If using gdm, open
append -dpi 100 or whichever you prefer.
HTH
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
Its a reference to the fact that the bitmapped fonts are only available in those resolutions and might have to be scaled for other ones. Chances are, you aren't actually using any bitmapped fonts any more (most modern apps don't bother, the only one I ever use that does is xterm), so it shouldn't actually affect you. Give it a go and see.
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.
The X11 clipboard is already quite powerful and supports a broad array of selection types, not just ASCII. A lot of apps only support ASCII, but that's not X11's problem. If any toolkit or app is reinventing the wheel by implementing a whole new clipboard, that really is quite brain-damaged.
Ita erat quando hic adveni.
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.