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.
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.
>They will be rendering the window system and applying it as a texture as fast render to texture paths become more common on vid cards, this is becoming a very good idea. If individual windows are blitted to textures and the desktop is reassembled from these windows textures, surely that would be a way to pmplement all the cool extensions and still ensure old X apps don't break? Because the X app doesn't know it's being rendered to a texture...
Actually, I was thinking it sounds more like Apple's Quartz Extreme than anything else. Although I guess since Quartz already served as the "inspiration" for Avalon, our comments are compatible. Whatever the inspiration, this will be a nice leap forward for X.
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
What are the memory implications of this ?
I think there is one thing we've learned time and time again -- today's memory considerations become largely irrelevant tomorrow. Yes, someone here mentioned that people today do still have video cards with 8MB or 16MB of video RAM. However, more and more people (largely driven by gaming "needs") are running cards with 128MB, 256MB, etc. A Moore's-esque law is in effect here as well (though not as extreme as with CPU cycles). The cost of adding a bit more RAM to a video card is rapidly becoming negligible relative to the total cost of the card.
You can even ignore the compression of the data itself (Apple's approach of today) -- by the time an X implementation like this is available, there will be enough users with effectively limitless video RAM to easily store the contents for a double-buffered very high resolution display.
So while I too have plenty of machines with 8MB video cards and I won't be running these X extensions on those machines, I have little doubt that in a year or two time it will be hard *not* to buy a card that could support this. And this, I believe, is a good thing.
Think about how few fundemental changes to the X architecture have been made to take advantage of the vastly improved video cards of today. This is a project that is actually forward looking and will use the capabilities of the hardware that we will all own tomorrow, whether or not we realized we wanted it today.
...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?
Then those users keep on using the "old" X, instead of this "new and improved" version. No-one is forcing them to use this new system, they can go on using the old system as long as they wish. But since there are lots and lots of people who could and would use this new feature, then why not do it? Because there are still some old geezers with vid-cards that have 4MB of RAM in 'em?
Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
I am consistently amazed at how myopic and conservative some old school open source projects are these days. The X old guard are seriously skirting making X completely irrelevant if they do not become more open and start adopting things that real users want. It takes money to make money, and it takes cycles to save cycles (i.e. it takes more resources to more efficiently save more resources). I can't believe there is resistence to an optional extension that would bring X more up to par with modern desktop environments like Aqua/Quartz.
It's 10 PM. Do you know if you're un-American?
I've heard many adjectives used about X windows, but this is the first polite one!
need a free COBOL editor for Windows?
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.
Additionally, any AGP-based video card will be able to raid the system RAM when it needs more memory.
Modern video cards are shipping with 128MB standard and 256MB for the high end, and that's likely to increase in the next year, probably to 512MB for the high-end. 64MB is pretty much the low-end today, and you can find 32MB or less on cards here and there, but they're not going to save you much money over the 64MB cards. Some people think it's insane for a graphics card to have that much RAM, but the reality is that the graphics card does more processing in games than the CPU, and it will be able to do so much more quickly if it has a lot of local RAM available instead of having to recover the space every time it needs to load a new model or map.
Additionally, the average system RAM is slowly increasing in off-the-shelf systems, to the point where many of the people I work with are thinking that 1GB isn't unreasonable for system RAM. This isn't really being driven by system requirements so much as the general feeling that people have that they should get more for the same price they paid a few years ago, and with RAM prices significantly lower than they were a few years ago, it's not hard for OEMs to give it to them. Sure, MY 2k and XP boxes need 512MB (actually, my 2k box only has 256MB, but it does need more), but the average person doesn't spend their day sitting in front of Visual Studio, either.
Of course, you are correct in that many people have the on-board video that runs off of system RAM, but again, how many of those people are actually using 512MB of system RAM? Additionally, if Linux is trying to move towards a more desktop-friendly environment, how many average users that would be looking at Linux would be using 512MB of system RAM?
-PainKilleR-[CE]
Now it is true that there are still people using 2MB, 4MB, 6MB, 8MB cards which could benefit from some of these advances, for example storing the window contents in video memory, since they can do a very fast bitblit to copy that rect into screen memory. However those people can use an implementation of all this in software, where the graphics are stored in main memory, and they should not experience any slowdown, only greater memory consumption. Which, of course, is the state of things today. Meanwhile it is nearly impossible to get a machine with less than 32MB of video memory today, and most everyone has at least 16MB now. (At least, if you have any kind of 3d accelerator.) It takes a bit under 8MB to store a 1600x1200x32bpp screen in video memory, leaving the rest for the most active applications (assuming no full-screen double buffering.)
If you DO decide to store everything in video memory (again, not going to be feasible on the older machines) then you get whatever bus bandwidth you have available to do it with. With modern machines (AGP4x and 8x) this is going to be essentially a non-issue for most X users. The only time you really blast your bus is when you're transferring large textures that have to be sent right now. It is hoped that X will one day end up using more of the video card's functions to do window compositing, minimizing the amount of data which must be sent. Even pixel shaders have a place here, for little things like drop shadows. (If you have a pixel shader engine which is otherwise idle, you might as well use it to draw your eye candy.)
64MB is plenty of ram, it's enough for eight full 32BPP 1600x1200 screen images and then some, or enough for a fully double-buffered display and a bunch of applications. Even 32MB is pretty healthy, it's not until you get down to 16MB cards (like say, the banshee) that you have problems.
Anything new enough to be an interesting desktop box, where you will want to burn power on eye candy, is going to have AGP graphics. You can get (crappy SiS) 64MB AGP video cards for under $30 shipped these days (at least in the US of A) so I'd say that's not a serious issue. Remember, this is the future we're looking towards, not the past. For all those old machines, you can always run older versions of XFree that don't do this stuff. Oh sure, you can't run the bleeding edge software, but who's trying to run the latest software on their old hardware? I defy you to get a significant amount of work done on a 386 running GNOME2 :P
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Meanwhile, Longhorn will do it automatically, and for older apps. I don't want to have to "learn to configure" a system to actually be readable. Heaven forbid I expect it to be well-designed and readable from the start.
Thereby screwing users who like small text and widgets so that they can fit more on the screen.
Configurability is a *good* thing. You can argue about what the defaults ought to be ("default to readable", like "default to secure", is a good catchphrase but defining a set of rules that can automatically produce the "right" thing in an unanticipated situation is non-trivial) but the almost infinite configurability of X is a strength, not a weakness.
Also, OverlyCriticalGuy, you need to be more critical of your own arguments: comparing current-generation X to MS vapor is fallacious.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.