X.Org 7.5 Released. Wait, Nope!

[phoronix]

Phoronix: X.Org 7.5 Released. Wait, Nope!

Today X.Org 7.5 with X Server 1.7 is scheduled to be released, per the release schedule that Daniel Stone proposed earlier this year. X Server 1.7 includes X Input 2 (a.k.a. Input Hotness) and Multi-Pointer X is now enabled by default (it has been in the master branch for about a year, but it has been disabled due to X Input 2 missing). This key piece to the open-source Linux desktop also features E-EDID support, the X Server no longer needing to symlink to Mesa sources, and a horde of bug-fixes. Aside from an updated X Server, X.Org 7.5 will include various updates to different input and graphics drivers.

http://www.phoronix.com/vr.php?view=13658

[89c51]

i just hope that X will die soon and all the operating systems depending on it will migrate to Wayland


(yeah right)

[[Knuckles]]

It's a pity that such a key piece of the free desktop continues to have manpower troubles...

[Vadi]

Yeah, it is.

But it also most be ridiculously hard to help contribute to it. Even using their API is a horrifying experience (no documentation whatsoever and such a weird, big, and complex format).

[Linuxhippy]

@phoronix: I don't see what all that bashing between the lines is good for.
Yes, Xorg has a hard time because of the lack of manpower, but instead of complaining all the time, why don't you help and start a call for developers?


@89c51: The question is what would you gain from switching to something different. What do you dislike about X, except they have manpower shortage? After all, most of the problems I experience are not design issues - they could be adressed with much less effort than rewriting the whole thing.

After all, you have to find people who develop Wayland as far as needed to be useable. Given the lack of Xorg devs I doubt this will happen anytime soon.

- Clemens

[puelocesar]

I still think Xorg always sucked and will always suck.. Apple should open source Quartz and we would all be happy.. Or, as I'm on dreamland today, X could just die as someone appear with something so awesome that put Quartz on its knees

[Michael]

@phoronix: I don't see what all that bashing between the lines is good for.
Yes, Xorg has a hard time because of the lack of manpower, but instead of complaining all the time, why don't you help and start a call for developers?

Bashing? I am not trying to bash them at all. This article in fact is to expose the situation and make it very clear and is to call out for developers and helpers, hence all of the text referring to companies that contribute, things other people can do, etc.

[puelocesar]

@phoronix: I don't see what all that bashing between the lines is good for.
Yes, Xorg has a hard time because of the lack of manpower, but instead of complaining all the time, why don't you help and start a call for developers?


@89c51: The question is what would you gain from switching to something different. What do you dislike about X, except they have manpower shortage? After all, most of the problems I experience are not design issues - they could be adressed with much less effort than rewriting the whole thing.

After all, you have to find people who develop Wayland as far as needed to be useable. Given the lack of Xorg devs I doubt this will happen anytime soon.

- Clemens

I always heard X have an archaic and non inviting code base.. How the hell that would be good for new developers wanting to contribute?

[panda84]

The question is what would you gain from switching to something different. What do you dislike about X, except they have manpower shortage? After all, most of the problems I experience are not design issues - they could be adressed with much less effort than rewriting the whole thing.

After all, you have to find people who develop Wayland as far as needed to be useable. Given the lack of Xorg devs I doubt this will happen anytime soon.
Restarting with a much more smaller and cleaner code base seems to have given KDE's desktop shell a new life... much more developers seems to be contributing to Plasma rather than the old KDesktop and development pace seems to be much quicker.
At first probably you'll miss the 20 years of features implemented in X, but what's good about Wayland is that you can run X in it.

[Linuxhippy]

X could just die as someone appear with something so awesome that put Quartz on its knees

1. XOrg is far more than graphics
2. Could you explain how Quartz is so much different compared to XRender?

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

[Vadi]

@Linuxhippy: Have a better method to attract developers to Xorg?

Share the secret...

[89c51]

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

:confused:

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 ???

[Fixxer_Linux]

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...

:D

[getaceres]

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.

[Wyatt]

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...

[RealNC]

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.

[Linuxhippy]

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

[Linuxhippy]

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.

- Clemens

[RealNC]

X still will run in userspace, so KMS and GEM won't make a lot of difference for typical 2D applications.

- Clemens

Why not? KMS moves the X driver to the kernel.

[Linuxhippy]

Why not? KMS moves the X driver to the kernel.

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

[GreatWalrus]

Very sad and scary to me the appearance of X.org development lately. I hope things will turn around also. Great article, Michael - I hope it opens some eyes out there.

[hubick]

I just want to say how much I appreciate the contributions of those who *are* working on X.org (individuals, Intel, RedHat, etc). Slow development is better than no development at all. Given the difficulty of even casual X hacking, we are lucky to have a team with the knowledge to refactor and improve the core API's.

Companies looking to contribute could examine what tasks new contributors could take over from the core team, freeing them up to concentrate on major architectural issues.

[puelocesar]

1. XOrg is far more than graphics
2. Could you explain how Quartz is so much different compared to XRender?

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

Hi Clemens, I cited Quartz, because when I installed Hackintosh on my machine, it used the Vesa driver, and it was no hw acceleration, but desktop and effects were way faster, smoother and stable then all my linux boxes using official drivers on them (intel and nvidia).

About rewrites, I'm a commercial software developer, and every time I have to work on ancient and bugged code, I always notice that it would be much more faster to just throw off the old codebase and write a new one then adapting an archaic, ugly and unmaintainable codebase. But obviously, our projects are *much* smaller then X, so I don't know if that applies..

[mattst88]

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

The current acceleration architecture, EXA, is only a stop-gap. See http://en.wikipedia.org/wiki/EXA

The long term plan is to move everything to OpenGL. Through Gallium3D, I assume. That is to say, 2D acceleration will be no more; only 3D will exist, with 2D done through 3D rendering.

[curaga]

The article was very true, and I like how it was serious at a date like today. I applaud Phoronix :)

[portets43]

@Michael

What about an interview with Kristian on Wayland and stuff ???


That would be great

[russofris]

The only current alternative to Xorg is Xfree.. You need to trust me when I state that we're using the better of the two.

Xorg needs developers and architects.

[RealNC]

I suppose the point was to move away from "X" (as in "The X Window System") in general to something else. The core of X is not needed today at all. It's there for the same reasons DOS is still there on Windows :P

[hax0r]

I heard Linus switched to subversion!

[BlackStar]

I suppose the point was to move away from "X" (as in "The X Window System") in general to something else. The core of X is not needed today at all. It's there for the same reasons DOS is still there on Windows :P

Many have tried to replace X. Until now, all have failed.

I dislike X, but mostly for its insane low-level API. Despite its shortcomings, it's versatile, stable and proven (in the API sense).

I don't believe a complete rewrite is feasible at this point in time (if it was, someone would have done it). IMHO, they way forward is to strip functionality from X11, bit by bit:

KMS is a great first step. I would also like to see input handling moved to the kernel (the kernel APIs are way more sane here!) I don't actually think that will happen (even with XInput2 looking dead in the water), but it would remove a large burden from the Xorg developers. Finally, I would like to see a controlled deprecation and rewrite of the worse and/or duplicated parts of the API.

I don't expect that will ever happen, so I've done what every sane person dealing with X11 does: write (or use) an abstraction layer so you don't have to look at its API anymore :D

Edit
Question: what is the point of XRender when we have OpenGL? No, really, why not simply design a render and compositing API that uses OpenGL underneath? Is there really something that XRender can do that cannot be done directly or indirectly with OpenGL?

[mattst88]

KMS is a great first step. I would also like to see input handling moved to the kernel (the kernel APIs are way more sane here!) I don't actually think that will happen (even with XInput2 looking dead in the water), but it would remove a large burden from the Xorg developers. Finally, I would like to see a controlled deprecation and rewrite of the worse and/or duplicated parts of the API.

Xinput2 is dead in the water? Really? (http://who-t.blogspot.com/2009/03/xi2-implementation-take-1.html)

Edit
Question: what is the point of XRender when we have OpenGL? No, really, why not simply design a render and compositing API that uses OpenGL underneath? Is there really something that XRender can do that cannot be done directly or indirectly with OpenGL?

XRender (http://en.wikipedia.org/wiki/XRender) dates from 2000 and XFree86 4.0.1. This was roughly when the DRI was implemented. They serve different purposes.

It's only been recently that the ability to move everything to 3D rendering has really been feasible.

[russofris]

Question: what is the point of XRender when we have OpenGL? No, really, why not simply design a render and compositing API that uses OpenGL underneath? Is there really something that XRender can do that cannot be done directly or indirectly with OpenGL?

Not all graphics cards have openGL support (in hardware or via their drivers). I am all for accelerating the entire desktop via openGL. It would certainly improve the quality of both the desktop and the drivers.

F

[bridgman]

Yeah, I think that was one of the attractions of something like XRender.

On a high end GPU you end up using the 3D engine for everything (in which case it's not *that* much harder to write a full GL driver), but on some chips you might have a fast alpha-blending 2D engine and a slow, undocumented or missing 3D engine.

[MostAwesomeDude]

As bridgman said, XRender/EXA can be done on chips without 3D engines. It's not the best API, but it's a decent bottom line and is going to be faster than software OpenGL. Also setup on the app side is much cheaper for XRender compared to OpenGL.

If people want to rewrite or replace X, go ahead. Don't expect any support until you can show people why you've come up with something better than what we've got in place already. Also please check to make sure your complaint isn't on the X12 wishlist already.

If you want to bitch about driver support, instead consider learning C and fixing your drivers. That's how I got into Xorg work, and if I can do it, anybody can do it.

~ C.

[BlackStar]

Xinput2 is dead in the water? Really?
Not dead then (phew!), but consider this: wasn't the *final* version supposed to be here already? Yet all we have is an early alpha! I mean no disrespect to the devs and I know there are good reasons for the delay, but this is indicative of an ailing project.

As bridgman said, XRender/EXA can be done on chips without 3D engines. It's not the best API, but it's a decent bottom line and is going to be faster than software OpenGL. Also setup on the app side is much cheaper for XRender compared to OpenGL.
I see. I was under the impression that we left 2D-only chips back in the era of the Matrox Mystique and the Voodoo 1 - are people seriously building chips with no 3d engine at this age and time? Even intel claims D3D10 and OpenGL 2.1 support in their recent hardware!

I get it that a solid 2d engine will be faster than a slow 3d engine. What I am getting at is, why not accelerate XRender using the 3d engine by default and only fall back to software/2d acceleration on specific chips? The alternative (separate EXA and OpenGL acceleration) seems rather inefficient, both wrt development resources and wrt utilization of modern hardware.

Another question: what does fglrx use to accelerate 2d? I've read that it doesn't support EXA. Is it XAA or is it something else entirely (where does Textured2D fit in this?)

[MostAwesomeDude]

I see. I was under the impression that we left 2D-only chips back in the era of the Matrox Mystique and the Voodoo 1 - are people seriously building chips with no 3d engine at this age and time? Even intel claims D3D10 and OpenGL 2.1 support in their recent hardware!

I get it that a solid 2d engine will be faster than a slow 3d engine. What I am getting at is, why not accelerate XRender using the 3d engine by default and only fall back to software/2d acceleration on specific chips? The alternative (separate EXA and OpenGL acceleration) seems rather inefficient, both wrt development resources and wrt utilization of modern hardware.

Hence Gallium.

[mattst88]

I see. I was under the impression that we left 2D-only chips back in the era of the Matrox Mystique and the Voodoo 1 - are people seriously building chips with no 3d engine at this age and time? Even intel claims D3D10 and OpenGL 2.1 support in their recent hardware!

No, you missed the point here.

Consider having documentation on the 2D-part of a graphics card, but lacking all 3D documentation. Think of R3,4,500 a few years ago.

In this situation, hardware OpenGL isn't an option, but XRender is. Hence, XRender is used.

[bridgman]

What I am getting at is, why not accelerate XRender using the 3d engine by default and only fall back to software/2d acceleration on specific chips? The alternative (separate EXA and OpenGL acceleration) seems rather inefficient, both wrt development resources and wrt utilization of modern hardware.

I don't think anyone is pushing back on running XRender over OpenGL, it's just that XRender is a lot easier to implement so on any new hardware you tend to have XRender implemented and in use long before you have OpenGL. The R6xx/7xx situation is a pretty good example -- EXA with XRender support has been running for a couple of months already.

The second point is that running a simple API over a complex API tends to be great for experimenting but tends not to give you optimal performance. XRender over bare hardware, or over Gallium3D, is likely to outperform XRender over OpenGL.

Where things get interesting, though, is when you start looking at higher level APIs (eg the GUI toolkits, or Cairo etc..). Maybe I'm missing something, but it seems like every few years someone implements Cairo over OpenGL and is very pleased with the results. Here's one that seems to be from 2004 :

http://lists.freedesktop.org/archives/cairo/2004-March/001061.html

Anyways, the key points here are :

1. Nobody is pushing back on using OpenGL, just on blanket statements that the ONLY implementation should be over OpenGL.

2. The primary reason for having non-OpenGL implementations of XRender is that by the time a new chip has OpenGL support it has normally had XRender support for a few months ;)

3. I have not seen test results, but my guess is that if you *did* compare XRender-over-OpenGL against XRender-over-raw-hardware that there would be a non-trivial performance penalty for using OpenGL. That's not a problem with OpenGL itself, just that XRender is a fairly simple function-at-a-time API while OpenGL is at its best drawing a bunch of things at once. That's why higher level APIs like Cairo seem like a better fit.

The reason people keep babbling about Gallium3D is that it shows promise as an API which can make good use of 3D engine hardware but with considerably less overhead than OpenGL when "drawing one thing at a time".

Another question: what does fglrx use to accelerate 2d? I've read that it doesn't support EXA. Is it XAA or is it something else entirely (where does Textured2D fit in this?)

Not exactly sure, AFAIK it's normally XAA API, using the 2D engine on pre-6xx parts, presumably using 3D engine on 6xx and higher.

[hax0r]

As bridgman said, XRender/EXA can be done on chips without 3D engines. It's not the best API, but it's a decent bottom line and is going to be faster than software OpenGL. Also setup on the app side is much cheaper for XRender compared to OpenGL.

If people want to rewrite or replace X, go ahead. Don't expect any support until you can show people why you've come up with something better than what we've got in place already. Also please check to make sure your complaint isn't on the X12 wishlist already.

If you want to bitch about driver support, instead consider learning C and fixing your drivers. That's how I got into Xorg work, and if I can do it, anybody can do it.

~ C.Amen to that.
Xorg is in great shape when looking at the ratio of code written to the amount of available devs.

[Anato]

I know some feel that this sucks but why can't the X.org start dropping features and drivers which doesn't have a maintainer, are old or the userbase is low? Why the lack on maintainers and need for support on some part have to drag the whole system down?

I think that good support for old hardware and features is beneficial to X.org and open source in general, but there is a trade of and at one point the old will become a burden. If there is small to medium size userbase to some feature and no maintainer then put it under risk of beeing drop away. If some company (or user) depends on that feature they will support it or work around it. Yes it is not nice but it is better than to let the whole system come to halt.

To show that I stand where my mouth is, if one of features I need is dropped I feel that it's sucks, but I'm not in the position to demand others to do the work for me. I would use some other method to get around the feature, support it my self or buy new hardware.

-Antti

[puelocesar]

3. I have not seen test results, but my guess is that if you *did* compare XRender-over-OpenGL against XRender-over-raw-hardware that there would be a non-trivial performance penalty for using OpenGL. That's not a problem with OpenGL itself, just that XRender is a fairly simple function-at-a-time API while OpenGL is at its best drawing a bunch of things at once. That's why higher level APIs like Cairo seem like a better fit.


Well, not exactly the same comparison, but there is a Qt4.5 benchmark that compares lastest Qt rendering using xrender, raster (made by them), and OpenGL. Raster seems 2x faster then xrender, and OpenGL seems something like 5x faster:
http://labs.trolltech.com/blogs/2008/10/22/so-long-and-thanks-for-the-blit/

[BlackStar]

From the link above:
Lubos: the raster graphicssystem doesn’t use any accelerated rendering, everything is done in software. Remarkably, this is usually faster than using XRender when it comes to pixmap transforms and gradients for example.
Mac OS X (PowerBook, Intel Core 2 Duo, 2.4 GHz, 4 GB Ram, NVidia GeForce 8600 GM)
Native: 9 Fps
Raster: 30 Fps
OpenGL: 215 Fp
X11 (Intel Pentium 4, 3 GHz, 1 Gb Ram, Nvidia GeForce 6600)
Native: 20 Fps
Raster: 36 Fps
OpenGL: 92 Fps
Obviously this is a single benchmark, but a) XRender on a P4 is twice as fast as (Quartz? Carbon?) Mac OS X on a Core2 (and we were saying that X11 was slow?) and b) the software renderer is twice as fast as XRender (ouch) and OpenGL is about 4.5 times faster (double ouch).

I'd love to see this test repeated on intel and radeon/radeonhd.

[bridgman]

Thanks, that's one of the articles I was trying to find last night.

Those tests seem shine a light on something different -- operations which are not accelerated by XRender today. The article doesn't say, but I imagine "native" on an X11 system refers to using XRender and whatever acceleration API is supporting XRender (XAA or EXA, I imagine).

The raster backend at least gives shadowfb-like acceleration for those ops while still being software rendered, while the OpenGL implementation hardware-accelerates most of the functions.

It's not "XRender-over-OpenGL", AFAICS, it's "a higher level API over OpenGL".

[puelocesar]

From the link above:



Obviously this is a single benchmark, but a) XRender on a P4 is twice as fast as (Quartz? Carbon?) Mac OS X on a Core2 (and we were saying that X11 was slow?) and b) the software renderer is twice as fast as XRender (ouch) and OpenGL is about 4.5 times faster (double ouch).

I'd love to see this test repeated on intel and radeon/radeonhd.

Notice also that native Windows run at 60fps, 3x faster then X11, so at least you can't say X11 is fast.. About OSX benchmark, what I notice from using it, is that everything that's made on non-Apple SDKs looks awful on it (maybe that's because they are such as*ho*es with third party developers), but apps made on Cocoa generally looks good, runs fast and have nice and smooth animations.

[smitty3268]

Found this informative comment regarding OSX performance:

This is correct. Our software backend for QPainter is faster than our CoreGraphics backend for most things. The CoreGraphics engine is faster than the raster engine when drawing large areas, because these operation are H/W accellerated by CoreGraphics, but in general our software engine beats native rendering on Mac OS X.

There is one architectural clash that causes some performance problems on the CoreGraphics backend, and that is state handling. CoreGraphics uses the PDF / PostScript model where you can only intersect a new clip with current clip and only multiply a new transformation with the existing one. Neither of the two states can be reset, only saved / restored. QPainter allows setting these states (and you can argue if this is wise or not, but it feels practical and its the way QPainter works so we don’t want to change it) regardless of what they previously was which means we need to do some nasty save/restore-stack handling on the CoreGraphics side, which is not fortunate performance wise…

Then there is the problem that CoreGraphics has a fixed overhead on all drawing operations. The fastest I’ve gotten is some 100.000 plain rectangles pr second (small ones, 4×4, 8×8, etc), while our software engine can do 10x that and style code and general widget code contains a lot of these small primitives, so the cost accumulates.

The benchmark does only repaints one widget, while an application is typically contains multiple widgets and the repaint / flush-to-screen logic is not optimal for Mac OS X at the moment, so an app like Designer won’t run any faster with -graphicssystem raster. We hope to be able to spend more time on those things in the coming months to iron out these things and make it really shine.

[smitty3268]

Notice also that native Windows run at 60fps, 3x faster then X11, so at least you can't say X11 is fast..

Note that they say there is no "native" mode on windows, they're just using raster by default there. So the fps is likely only faster there than the raster mode on linux because the computer is a Core2 Quad versus a Pentium4.

But yes, XRender is slow.

[BlackStar]

Note that they say there is no "native" mode on windows, they're just using raster by default there. So the fps is likely only faster there than the raster mode on linux because the computer is a Core2 Quad versus a Pentium4.

I'm pretty sure GDI is the "native" mode on Windows and it is accelerated on pretty much everything out there. It's not known as a speed-demon however.

As far as I can tell, on Windows you can choose between GDI (accelerated), GDI+ (deprecated, not accelerated), DirectDraw (deprecated), WPF (accelerated, .Net-only) and Direct2D (maybe the worst API ever designed by Microsoft, which is saying a lot) for 2d graphics. Out of these, only WPF is actually worth using - but it's .Net only which limits its usefulness.

So yes, the X11 API may be ugly, XRender may be slow, but there are worse things out there.

[puelocesar]

Note that they say there is no "native" mode on windows, they're just using raster by default there. So the fps is likely only faster there than the raster mode on linux because the computer is a Core2 Quad versus a Pentium4.

But yes, XRender is slow.

Oops, sorry I didn't saw that :( shame on me ...

[MostAwesomeDude]

I know some feel that this sucks but why can't the X.org start dropping features and drivers which doesn't have a maintainer, are old or the userbase is low? Why the lack on maintainers and need for support on some part have to drag the whole system down?

We do. Many drivers are marked as unmaintained and only receive trivial janitorial updates.

[sandain]

If X is such a nightmare to work with, why hasn't there been more interest in OSS alternatives like Y (http://www.y-windows.org/)? As a software developer myself, I realize drastic changes only create headaches, but sometimes they are needed to move ahead.

[Vadi]

I didn't even know Y existed.

[yotambien]

OT

Perhaps one of you, guys, can answer a question that lingers on my head every time I work with a heavy pdf file. I think I read somewhere that poppler uses cairo and that this uses HW acceleration when available (I don't actually know what that means, mind you). Why is it that displaying pdfs is rather slugish? Out of pure ignorance I'd say that drawing a 3D landscape like any of the ones you get playing a FPS is more cumbersome than displaying a bunch of fonts...

[Vadi]

I'd attribute this one to the program itself. Evince was really slow on displaying the pdfs, but Adobe Reader (yeah it looks horrid with the custom cursor and fails to open a browser properly) just flies on them.