If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
I have to agree about the quite ugly code-base, I don't want to predict how a re-write would look like once its has all the features people *depend* on.
- Clemens
i think (and i might be very wrong) that the only thing that people will depend -and wayland doesn't have- is network transparency
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 ???
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...
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.
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...
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?
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.
It must die or it must be rewritten from the ground up .... 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?
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.
?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.
You are quite unspecific. Does xorg feel slow, or the applications and toolkits using it?
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; 01 April 2009, 10:58 AM.
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.
X still will run in userspace, so KMS and GEM won't make a lot of difference for typical 2D applications.
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...
Comment