X.Org 7.5 Released. Wait, Nope!

[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? As a software developer myself, I realize drastic changes only create headaches, but sometimes they are needed to move ahead.