Phoronix Test Suite Contributor
@Linuxhippy: Have a better method to attract developers to Xorg?
Share the secret...
Senior Member
i think (and i might be very wrong) that the only thing that people will depend -and wayland doesn't have- is network transparencyOriginally Posted by Linuxhippy
probably there are more things missing right now but as far as i understand it this is what requires the most work
@Michael
What about an interview with Kristian on Wayland and stuff ???
Senior Member
Another april's fools joke could be : UT3 is out for linux and Epic will open-source their engine.
ATI, partnership with Epic, issue the same day a fglrx 9.4 that fully corrects all the bugs remaining (no video tearing, +20% performance in OpenGl) and the Xfi drivers are now open-sourced as well by creative to give a real AAAAA game enjoyement to linux users...
Junior Member
It must die or it must be rewritten from the ground up. The code is huge and ugly and contributing is almost impossible because of the lack of documentation. Now it comes the lack of manpower.
¿What about starting from an implementation of XRender that actually accelerates (instead of decelerating) the rendering? ¿Have you seen that QT 4.5 using raster rendering (software) is much much faster than using native rendering (XRender)? ¿Is it so difficult to have simple alpha blending without hardware acceleration in a 2GH+ machine? Most of the simple effects in Mac OS X like translucency work at full speed without hardware acceleration. Windows had Alpha Blending since Windows 2000 and it was quick even without hardware acceleration. ¿Why then Xorg needs a full 3D graphic card just to let a window know what is behind it? ¿Why does Xorg feel so slow compared to OSX and Windows even with the fastest graphic card?
¿Can you solve all these problems with Xorg keeping the 20 years old code while solving in a small amount of time the future challenges that may arise in the near future? In the past Xfree didn't keep up with the rest of the graphic systems and, although Xorg implemented some of these features that were missing for long, they are implemented in a slow, semi working fashion.
Senior Member
The way I see it, X.org is still suffering from a "monolithic" hangover. The code is hard to understand, and the system is hopelessly complex, only exacerbated by the arcane entanglement of video drivers as we've come to know them. To come in as even an experienced programmer and attempt to work on X.org, you'd probably need a good year to even begin to get on your feet in a meaningful way, even after its modular breakdown.
And the documentation is spotty and hard to follow, as I recall it, so that doesn't help either. I understand very well that good documentation is hard to write, especially on something as huge as an X implementation, but you call it like you see it, no?
EDIT: Oh wow, I start typing, get distracted for half an hour, finish my post, and in the meantime a bunch of people have declared, in no uncertain terms, exactly what I said. That's actually really depressing...
Last edited by Wyatt; 04-01-2009 at 09:38 AM.
Senior Member
I suppose that those problems are due to X being almost completely userland right now. OS X and Windows do a lot of the GUI stack in the kernel. If I understand correctly, this is going to change "soon", with KMS and GEM, which hopefully will up the GUI performance a lot.
Senior Member
So basically your only problem is performance?! Well, when using XAA you get composition without hw accaleration and it should work as well as it does on OSX.
After all this is more or less a problem with drivers and the way drivers are written. There are no state-trackers and usually per-primitive overhead is quite high.
Here Gallium3D could make a real difference.
You are quite unspecific. Does xorg feel slow, or the applications and toolkits using it?¿Why does Xorg feel so slow compared to OSX and Windows even with the fastest graphic card?
¿Can you solve all these problems with Xorg keeping the 20 years old code while solving in a small amount of time the future challenges that may arise in the near future? In the past Xfree didn't keep up with the rest of the graphic systems and, although Xorg implemented some of these features that were missing for long, they are implemented in a slow, semi working fashion.
Have you thought about toolkits doing stupid things? E.g. I've just reported a problem to trolltech where XRender was used in a very inefficient way for non-aa rendering in QT.
Which features have been implemented slow and semi working, except XRender (which has been mostly fixed recently)?
- Clemens
Last edited by Linuxhippy; 04-01-2009 at 09:58 AM.
Senior Member
X still will run in userspace, so KMS and GEM won't make a lot of difference for typical 2D applications.
- Clemens
Senior Member
Why not? KMS moves the X driver to the kernel.
Senior Member
No, KMS only moves the mode-setting part of the driver into the kernel. Mode setting is usually a very rare event, and has nothing to do with 2D/3D performance.
GEM moves memory management into kernel, but the whole 2D accaleration code is still running (mostly) in userspace.
After all, why should it make a difference if the driver is running in userspace or kernel?
The main problems of bad 2D performance are elsewhere...
- Clemens
Posting Permissions
Reply With Quote