“The freedesktop.org X hacking is low-profile unstableware at the moment, but one particular proposal interests me the most“, Havoc Pennington (of Red Hat, Gnome and freedesktop.org fame) is writing on his dev blog. Havoc discusses the new features and explains the new levels of the ‘modernization’ of this XFree86 fork.
freedesktop.org Pushes for New X Server
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I do hope this happens and SOON.
X has to be the last major windowing system to implement these features. OSX has it, so does Longhorn, and both are DONE already!
If only the XFree86 devs weren’t so conservative. I guess that’s why we have Xouvert
1) Which fork is he referring to? Xouvert? I thought freedesktop was hacking the XF86 code directly, but I guess I’m wrong. Could someone “in the know” explain this to me? I’m about as confused as someone turning on the tv and watchin a soap opera.
2) Havoc said, I’m waiting for something I can try out to appear in jhbuild so I can make metacity super-leet.
I just found that to be funny
3) This is his blog (albeit dev related). Should we take it to mean that if he writes on it, that goes on the record as freedesktop.org’s official stance?
X has to be the last major windowing system to implement these features. OSX has it, so does Longhorn, and both are DONE already!
Wrong. XFree86 doesn’t have “those” features. Many implementations of X do.
>1) Which fork is he referring to? Xouvert?
No. freedesktop.org has its own effort towards X, with the help of Keith Packard (of fontconfig fame and of shouting-Xfree86-fame last April)
> Should we take it to mean that if he writes on it, that goes on the record as freedesktop.org’s official stance?
Havoc doesn’t spend time writing nonsense. If he says something, it is what it is and nothing else.
XFree86’s current model for handling exposes is truly pathetic. As RAM is cheap but CPU is not, why not buffer the entire window instead of having clients handle exposes? On my K6-2 500MHz, applications block anywhere from 5-30 seconds due to Window Maker’s virtual desktop implementation.
The X protocol relies on intelligent drawing/event handling by the clients, when the same logic could be placed server side and remove the need for complex client side drawing/event handling logic. After all, the server need only be implemented once, so why force unnecessary application logic upon the clients?
Of course, the server will still need to send an expose event for window resizes, but this will improve X compositing and rendering substantially.
No. freedesktop.org has its own effort towards X, with the help of Keith Packard (of fontconfig fame and of shouting-Xfree86-fame last April)
And is this freedesktop.org effort forking the X.org codebase or XFree86? Have they made an announcement I missed? I thought I knew what was going on with X in general, but I guess I’m out of the loop now
> Should we take it to mean that if he writes on it, that goes on the record as freedesktop.org’s official stance?
Havoc doesn’t spend time writing nonsense. If he says something, it is what it is and nothing else.
Even still, there is a difference between writing the blog to let people know what he [i]is doing with X (along with freedesktop.org), and writing it to let people know what he wants to do with X. That’s what I meant (I wasn’t saying that it was a mistake to assume his statements reflect freedesktop.org as a whole, they do either way).
By the way, any chance of a preview button? I always forget my closing tags
I suppose it’s my fault for not checking. By the way, do you happen to know what’s going on over at xouvert.org? You seem to be in the know about XFree86 and all the politics going on, and their website hasn’t been updated in a while, and there was supposed to be a release last month.
I really don’t know what problem they’re trying to solve here. Expose handling performance isn’t the issue anymore, resize performance is. The only time I notice a lagged expose is when I use a menu to perform some complex operation, so the menu goes away, but the app below doesn’t repaint because its busy. This could easily be fixed be using SaveUnders, rather than buffering the contents of the *entire* window.
The only thing that this really gains you, aside from a huge memory hit, is those stupid translucent windows. I’d rather have my 100MB of RAM back, thank you very much.
Xouvert.org most likely will fail. Many people have expressed concerns with the group’s skill set and long term staying ability. What the group has proposed is a lot of work for developers new to Xfree. It has none of the real Xfree players behind it and has been ignored by everyone that ‘matters’ in the world of Xfree. Also, Xouvert.org was supposed to have a release a while ago but nothing came of it.
I know the arguments you give are true but give them a chance to prove themselve. There’s nothing more frustrating than starting a project and hearing everyone say how you won’t be able to handle it.
And is this freedesktop.org effort forking the X.org codebase or XFree86? Have they made an announcement I missed? I thought I knew what was going on with X in general, but I guess I’m out of the loop now
I don’t think they made an announcement, at least i never saw one, but there are several projects in the freedesktop.org cvs . One of them, xserver, is a fork of the xfree X server (only the server) that uses a different graphics driver interface (kdrive). Then there are several projects for all the X libraries, all of them using the autoconf/automake toolchain and pkgconfig, making building them very easy. Just check the projects page on freedesktop.org, there’s quite some stuff going on.
I really don’t know what problem they’re trying to solve here.
Clearly the primary problem being solved is X’s inability to alpha composite transparent windows.
Expose handling performance isn’t the issue anymore, resize performance is.
I beg to differ… expose handling performance is pathetic on my K6-2 500MHz. It takes about a full second for Opera to handle an expose event at 1280×1024, at which point I can watch it vertically redraw from top to bottom.
In my opinion, it makes much more sense to eliminate the need for clients to handle exposes in any case besides a window resize than it does to expect every X11 application to be recoded with more efficient expose handling, especially considering that many applications are now targeting multiple platforms using something like Qt and can’t have a rendering model which is tightly integrated with the X11 event system.
The only thing that this really gains you, aside from a huge memory hit, is those stupid translucent windows.
Aren’t you forgetting the number of context switches necessary for the protocol chatter between the X server and client necessary to handle the expose? I assure you this is painfully slower than Win32 on the same hardware.
I’d rather have my 100MB of RAM back, thank you very much.
And I’d rather not have to wait an entire second after switching virtual desktops for the applications to be usable.
100 MB RAM for a speedup of one full second? WOW! Now everybody would want that, wouldn’t they?
100 MB RAM for a speedup of one full second? WOW! Now everybody would want that, wouldn’t they?
The point is computation speed versus memory, and for most people upgrading RAM is much easier than upgrading the processor. Also, the post talks of selectively enabling this compositing method for specific windows, meaning that you need not necessarily double buffer every window being displayed.
The 1 second delay is merely an annoyance, but if you factor in a few thousand virtual desktop switches per day, those one second delays start to add up.
I beg to differ… expose handling performance is pathetic on my K6-2 500MHz. It takes about a full second for Opera to handle an expose event at 1280×1024, at which point I can watch it vertically redraw from top to bottom.
I have a k6-2 450Mhz with 4MB PCI Matrox Millenium II running at 1024×768 and I don’t have that problem as severe as you say.
Could it possible Xfree86 is not good with the larger resolutions on slower systems?
However, a more exciting compositing manager might apply embellishments/transformations to the window contents prior to drawing them, possibly drawing them using an API such as OpenGL
I think that qualifies as a little more exciting than translucency.
4 this.
I think all tries are good!
If they turn out bad…delete them…
It sounds like you’re using a driver which doesn’t support the Render extension, actually.
My Celeron 333 did just fine when switching with a G200.
-Erwos
Create a switch on the server so the user can select how to buffer windows.
The problem there trying to solve is: The server only has the client draw the visable section of its windows.
Throw the switch…
The server now tells the client that the windows is always fully visiable and then does the compositing to display the windows according to the settings. The big advantage here is: moving, covering, and uncovering a window events don’t need to be sent to the client; thus, the client doesn’t need to redraw the screen. This also reduces a lot of network traffic; thus, making it better for dial-up/low speed connections. The disadvantage is that the server will require more memory to keep the fully rendered windows.
Other advantages are:
1) Handycap asscessablity. Zoom & Pan become server functions and not program functions.
2) The ability to do transparancies.
3) The ability to add shadows to windows.
As part of the Sky++, C++ API for SkyOS, the whole display will be an OpenGL scene managed by a display server app.
[/plug]
We don’t know if longhorn is finished yet and it’s not going to come out for another 2-3 years at least.
It sounds like you’re using a driver which doesn’t support the Render extension, actually.
On my duron 1300/geforce4 ti, even with render accel enabled, if i open konqueror, maximize it and then drag another app’s (smaller) window over konqueror i can clearly see the redrawing. Some people don’t seem to mind this at all, others (like me) are a lot more picky.
Anyway if they do push the window manager into the server and get opengl to work they migh as well render each window as polygon textures and let hardware zbuffer sort it all out.
Wasn’t there a move a while back to push more of the work onto the server so that when the display went from the server to client, everything that needed to be done, was done already at the server end thus meaning there was no “real work” done by the client?
Also, even if some of these ideas are implemented, it still doesn’t get away from the crappy drivers that are being put out by hardware vendors or there-lack-of. How long has the Parhelia been out and yet the best Matrox can muster together is a crapp 2D driver which is still beta quality.
Sure, I can understand that these companies can’t push out a driver for ever consumer card, but for goodness sake, this is a workstation card! these companies have to stop being so bloody paranoid and start giving out the specifications required to write drivers and allow the opensource community to develop them.
The opensource drivers that have been developed to specifications given out by graphic card companies are superior to what is put out by the card producers who insist on developing the drivers themselves.
It took Creative years to finally put the SoundBlaster Live! drivers opensource, claiming that for some reason if they did, the whole world would come to a crashing end and they would go out of business. Here we are, many years later with opensource Sound Blaster drivers and Creative is still here and still profitable.
Pro or Contra doeasn’t matter,
we saw many of this no?
An idea is emerging though,
The X Windows, platform,
needs update in any form.
I agree. It’s insane that they keep their drivers to themselves, as if they made money off of it. It’s the hardware that they make money from. The only thing I can think of is they are worried about their cards being reverse engineered or something. Still nuts.
It’s not just that. They may have agreements with their own suppliers not to release technical details or source code (kind of like the situation with Linksys routers that use Broadcom chips). Of course they may just be holding back for their own reasons (ie. lack of appreciation of the value of open sourcing drivers/hardware details).
@Anonymous: A real OpenGL-rendered GUI (like what zephc said about SkyOS) would be interesting. OpenGL-accelerated compositing is just window transparency.
@Bascule: There is not a huge amount of protocol chatter for a simple expose event. There is some, but any client-server setup will have that.
@Sagres: Don’t see that here. I can move or resize windows on top of Konqueror and I see *zero* redraw. Even in XP, I’ll see bad redraw when resizing windows on top of IE. I’m using KDE 3.2, but I don’t think they’ve added double buffering to Konqueror since then. My machine isn’t appreciably faster than yours — 2GHz P4 (about as fast as a 1.5 GHz Athlon) and GeForce4 MX. I just don’t see expose handling as a problem. I can’t find a single KDE app (tried KWord, Konqueror, KFind, KStars, and a bunch of others). I can resize on top of them, move on top of them, and I get *nothing*. I can see a tiny bit in OpenOffice, but that’s barely noticible over the 25ms lag of my LCD. Like I said, the only thing I’ve noticed is some lag when opening up complex menu items (like the configure dialog in some programs) and that can be fixed with Save Unders.
I’m not sure if windowmaker supports this, but Xfree86 Does have a feature where it buffers all the windows in memory..
To you Device section add
Option “backingstore” “on”
It does wonders with KDE..
I’ve head that GTK doesnt support it though..
I meant using konqueror as a web browser, i notice little redraw when it’s in file manager mode.
Ps: i’m using kde 3.1.3.
Jeez – sounds like there is something wrong somewhere. I have a K6-2 500MHz myself and don’t find those problems. Right now, I have 192MB RAM and a GX440 video card, so I wouldn’t expect the system to be slow, but recently, all I had 64MB RAM and a Cirrus Logic GD5465 (a software driven card), and still never had that problem even when using Mozilla or OOo, never mind Opera.
Sorry this post isn’t much use to you, because I cannot offer any helpful hints, but it really does sound like something is wrong somewhere.