Hardware Based XRender Slower than Software Rendering?

Neon Spiral Injector writes "Rasterman of Enlightenment fame has finally updated the news page of his personal site. It seems that the behind the scenes work for E is coming along. He is investigating rendering backends for Evas. The default backend is a software renderer written by Raster. Trying to gain a little more speed he ported it to the XRender extension, only to find that it became 20-50 times slower on his NVidia card. He has placed some sample code on this same news page for people to try, and see if this is also experienced on other setups."

The damndest thing.

[Raven42rac]

I have used both ATI and NVIDIA,(and 3dfx, and matrox, but staying relevant). Generally the NVIDIA cards I have owned have been vastly outperformed by the ATI cards right off the bat, without tweakage. (This is under Linux, mind you) Even with tweakage, in my experience, you rarely get the full potential from your card.

One word:

[i_am_nitrogen]

Irix.

IrisGL or OpenGL (I think OpenGL is based on IrisGL, so Irix probably now uses OpenGL) is used extensively in Irix, for both 2D and 3D.

Not enough details

[bobtodd]

Raster doesn't say whther he had 'Option "RenderAccel" "True"' enabled, which you must do on Nvidia cards if you want XRender acceleration.

Here is the entry from the driver README:

Option "RenderAccel" "boolean" Enable or disable hardware acceleration of the RENDER extension. THIS OPTION IS EXPERIMENTAL. ENABLE IT AT YOUR OWN RISK. There is no correctness test suite for the RENDER extension so NVIDIA can not verify that RENDER acceleration works correctly. Default: hardware acceleration of the RENDER extension is disabled.

Following that option, this one is noted:

Option "NoRenderExtension" "boolean" Disable the RENDER extension. Other than recompiling the X-server, XFree86 doesn't seem to have another way of disabling this. Fortunatly, we can control this from the driver so we export this option. This is useful in depth 8 where RENDER would normally steal most of the default colormap. Default: RENDER is offered when possible.

Raster's on holiday

[Rabid Penguin]

Normally, he would answer some questions or comments posted about something he has written, but he will be out of town for at least a few days.

I highly doubt he meant for this to get wide-spread exposure beyond developers of Enlightenment or X. Since it has, this is a good opportunity. I'll make this clear for anyone that didn't catch it, raster WANTS XRENDER TO BE FASTER! If there is a way to alter configuration or to recode the benchmark to do so, he wants to know about it.

Rather than posting questions about his configuration (which he can't answer right now), grab the benchmarks that he put up and get better results.

Now back to your regularly scheduled trolling...

Unfair comparison

[Anonymous Coward]

The numbers being reported for this benchmark are at best questionable--yeah, like that's new. The imlib image is composed off-screen and then rendered at the last moment to the display. The Xrender, non-off screen, version has the penalty of having to upgrade the physical display so frequently. If you make imlib2 render the image to the screen *every* draw, you end up getting results very similar to the Xrender on-screen display. Now, the fact that the Xrender off-screen display is so poor *is* a concern.

nVidia Linux woes

[bleachboy]

I have an nVidia GeForce2 Ultra, and recently upgraded my kernel to 2.5.75. It caused my X graphics to become unbelievably slow -- like 2400 baud modem slow when doing a directory listing or anything where text was scrolling. Downgrading to 2.4.21-ac4 (ac4 needed for some Adaptec drivers) and it was back to fast again. Further, my favorite 3D shooter was about 60 fps faster with the 2.4 kernel. The kernels were compiled identically, or at least as identically as you can get with 2.4 vs 2.5. Here's a few tips I can offer to the nVidia users out there:

• In case you don't know, nVidia provides official (but woefully non-GPL) drivers [nvidia.com]. They also have a message board [nvnews.net] which I found to be quite informative at times.
• Compile your kernel with MTRR support. It will speed things up a great deal.
• Compile your kernel without AGPGART support. The nVidia driver(s) are faster.
• If you want to try the nVidia driver with a 2.5 kernel, you'll need a patch [minion.de].
• If you have an nForce chipset, make sure to add "mem=nopentium" to your kernel boot parameters, or else your system will be incredibly unstable. Better yet, ditch your nForce chipset (I did) since the Linux support totally blows, at least for now. Give your old nForce chipset to your wife, girlfriend, mother, Windows box, or whatever.

Re:2D acceleration using OpenGL?

[Rabid Penguin]

Yes, and yes. :-)

The current version of Evas is actually the second iteration. The first version had a backend written for OpenGL, which performed quite well for large drawing areas, but was sluggish with many small areas (bad for window managers). The software engine easily outperformed in those cases, and will be used for the resulting window manager's border drawing.

For now, there is not an OpenGL engine in Evas, because of time constraints. E has a relatively small active development team atm, so it's difficult to say when someone will get around to adding the OpenGL engine. There should be one eventually, all nicely encapsulated except for a couple setup functions.

Re: Graphics cards and computation

[Black Parrot]

> There has been some work on using graphics cards for computation. The tough part is figuring out how to rephrase your algorithm in terms of what the GPU can handle.

Isn't there a lot of sloth involved in reading your results back as well?

Meanwhile, users of GCC can exploit whatever multimedia SIMD instructions their processor supports by telling the processor you want to use them. For x86 see this [gnu.org] and this [gnu.org]; for other architectures start here [gnu.org]. (Notice the GCC version in the URL; the supported options sometimes change between versions, so you should look in a version of the GCC Manual that matches what you're actually using.)

I confess I haven't benchmarked these options, but in theory they should boost the performance of some kinds of number-crunching algorithms.

BTW, Linuxers can find what multimedia extensions their CPU supports with cat /proc/cpuinfo, even from a user account. Look for multimedia support in the list at the end of the cpuinfo. Lots of those extensions only support integers or low-resolution fp numbers, but IIRC SSE2 should be good for high-precision FP operations. Use google to find out what your extensions are good for.

And post us back if you do some benchmarking, or find some good ones on the Web.

Render Bench

[AstroDrabb]

I just ran the render bench from the link. The results are pretty amazing.

Available XRENDER filters:
nearest
bilinear
fast
good
best
Set up...
--ROUND 1
--
Test: Test Xrender doing non-scaled Over blends
Time: 22.842 sec.
--
Test: Test Imlib2 doing non-scaled Over blends
Time: 0.501 sec.

--ROUND 2
--
Test: Test Xrender doing 1/2 scaled Over blends
Time: 11.438 sec.
--
Test: Test Imlib2 doing 1/2 scaled Over blends
Time: 0.188 sec.

--ROUND 3
--
Test: Test Xrender doing 2* smooth scaled Over blends
Time: 225.476 sec.
--
Test: Test Imlib2 doing 2* smooth scaled Over blends
Time: 3.963 sec.

Re:One word:

[Krach42]

You forgot about an even more common example... QUARTZ! Apple's OSX does all rendering through Quartz, (as PDFs) which is accelerated by OpenGL, and called QuartzExtreme.

Re:I actually downloaded and ran his benchmark

[saikatguha266]

Whops. Mod me down on that last one. The image I described was the opaque image that is being used as a background, and the bufferring threw off the printf vs. x sync I am guessing. On closer examination ... imlib does seem to work ... but doesn't display anything while its doing stuff ... only the final image.

Re:An important truth about X

[OrangeTide]

X is small and fast(at least XFree86 [xfree.org] is). When you look at how much virtual memory it has mapped in. (using 'ps' for example). You also are seeing the amount of memory mapped in for the video frame buffer. Have a 32Mb video card? Well at *least* 32Mb of your virtual address space isn't mapping into system ram, it's mapped into video ram.

Also, with any application, the code space doesn't take system RAM in the same sense as data space does. Normally you map in pages of memory that point straight to the I/O device the executable exists on. (this is called mmap [freebsd.org]). You only have a few pages of system memory actually in-use, for the areas of the program that are currently executing or have executed recently. It's pretty easy to draw an analogy to this and swap memory, except this is a lot simpler to implement in a kernel.

I've build mini systems where XFree86 and Linux and a handful of fun apps ran in 4Mb of RAM. For a diskless system, you would want to use something like XIP (eXecute-In-Place). that way you don't have to go crazy loading in applications into system RAM or have funny mmap things that try to cache memory. (if it's all in RAM disk why are you caching RAM with more RAM? :)

Also check out the AgendaVR3 pda [agendacomputing.de]. I own one of these gizmos. The company is basically out of business, but their PDAs definently ran XFree86 and a ton of apps with only 8Mb of flash and 8Mb of RAM.

Of course. If XFree86 is still too big for you, there is always The MGR Window System [hack.org]. This fun program is designed to basically allow you to run multiple shells on the same screen in a graphical way, with each one having it's own font size if you want. It looks like monochrome X11, but it's a lot smaller. It also works over both telnet and ssh quite transparently. (all the GUI stuff is encoded in vt100-like escape codes). You can even do real graphics with it, look at this big screen shot [hack.org] if you don't believe me. Also it's open source, which is good because it probably hasn't used on linux after kernel version 1.2, have fun tinking with it. :)

Re:2D acceleration using OpenGL?

[mvdwege]

On using OpenGL in multiple windows....

How well does Linux do with this?) Try running a few OpenGL apps that don't stress the graphics hardware at the same time. Do they slow down?

While my graphics hardware is not quite representative (the Matrox G450 is not known for great 3D performance), I ran two instances of glxgears.

Short conclusion: MesaGL on Linux has the same problem. Long conclusion: the windows showed noticable slowdowns, up to the point where animation was suspended in one window while the other ran, with the system switching the running window at seemingly random intervals.

System specs:

• Athlon 1600XP
• MSI K7TPro2 Motherboard
• Matrox G450 AGP Graphics Card
• Linux kernel 2.6.0-test3
• XFree86 4.2.1 (Debian patchlevel 9)

Hope this helps,

Mart

Re:accelerated?

[Spy Hunter]

Well I ran Renderman's benchmark on my Radeon 9100/Athlon XP 2800 system, and here are the results (edited for lameness filter):

*** ROUND 1 ***
Test: Test Xrender doing non-scaled Over blends
Time: 15.925 sec.
---
Test: Test Xrender (offscreen) doing non-scaled Over blends
Time: 15.927 sec.
---
Test: Test Imlib2 doing non-scaled Over blends
Time: 0.321 sec.
*** ROUND 2 ***
Test: Test Xrender doing 1/2 scaled Over blends
Time: 7.125 sec.
---
Test: Test Xrender (offscreen) doing 1/2 scaled Over blends
Time: 7.134 sec.
---
Test: Test Imlib2 doing 1/2 scaled Over blends
Time: 0.133 sec.
*** ROUND 3 ***
Test: Test Xrender doing 2* smooth scaled Over blends
Time: 131.495 sec.
---
Test: Test Xrender (offscreen) doing 2* smooth scaled Over blends
Time: 131.703 sec.
---
Test: Test Imlib2 doing 2* smooth scaled Over blends
Time: 2.487 sec.
*** ROUND 4 ***
Test: Test Xrender doing 2* nearest scaled Over blends
Time: 113.890 sec.
---
Test: Test Xrender (offscreen) doing 2* nearest scaled Over blends
Time: 113.945 sec.
---
Test: Test Imlib2 doing 2* nearest scaled Over blends
Time: 1.778 sec.
*** ROUND 6 ***
Test: Test Xrender doing general nearest scaled Over blends
Time: 197.817 sec.
---
Test: Test Xrender (offscreen) doing general nearest scaled Over blends
Time: 197.800 sec.
---
Test: Test Imlib2 doing general nearest scaled Over blends
Time: 5.171 sec.
*** ROUND 7 ***
Test: Test Xrender doing general smooth scaled Over blends
Time: 268.509 sec.
---
Test: Test Xrender (offscreen) doing general smooth scaled Over blends
Time: 268.656 sec.
---
Test: Test Imlib2 doing general smooth scaled Over blends
Time: 7.507 sec.

Obviously XRender is getting crushed here by Imlib2. There are a million reasons this might be happening, it's definitely worth looking into. In the best Slashdot tradition, here's some wild speculation about what might be causing the slowdown:

• Renderman's code might be giving an unfair advantage to Imlib2. The Imlib2 results are never shown on the screen. However, XRender is tested both with display and without, so it seems like it should be fair.
• Renderman's code might be using XRender in an inefficient way. I'm no X programming expert so I have no idea if what he's doing is the best way to do it, but Rasterman is supposed to be some sort of expert in producing nice fast graphics on X so I'd say this is unlikely.
• XRender might not be hardware accelerated for some reason, probably having to do with driver configuration or something. But geez, does the software rendering have to be that slow? Maybe they could learn something from Imlib2.
• The hotly debated "X protocol overhead" might be causing this slowdown. But given the magnitude of the slowdown, I think this is unlikely.

Hopefully someone knowledgeable like Keith Packard himself will come and enlighten us with the true cause.

Nothing is wrong with XRender?

[Anonymous Coward]

I ran the benchmark on a VIA MVP3 motherboard with AMD K6-3+ 400 MHz CPU and GeForce2 MX 400 vide card. With RenderAccel option enabled, the unscaled test runs two times faster with XRender, but when that option is set to "false" in XF86Config, the results are as follows:

Test: Test Xrender doing non-scaled Over blends
Time: 16.234 sec.

Test: Test Xrender (offscreen) doing non-scaled Over blends
Time: 16.108 sec.

Test: Test Imlib2 doing non-scaled Over blends
Time: 1.932 sec.

That was with hardware acceleration disabled. I was surprised that enabling the hardware acceleration speeds the first test up by that much (up to 32 times actually).

I also confirm the previous posters' findings that Imlib2 tests don't draw anything onscreen.

Re:2D acceleration using OpenGL?

[Rufus211]

Must be your hardware. I have an Ath 2700 XP with a ATI 9800 running Debian with X 4.3

Single glxgears: 3600
3 glxgears: 1200
5 glxgears: 700

(All aprox numbers). So basically it scales almost perfectly with the number of open windows.

Re:accelerated?

[Doug Neal]

The NVidia drivers provide experimental RENDER acceleration. I tried it out recently on my laptop and it's not called experimental for nothing - it's rather unstable. Every so often XFree86 would lock up. Mouse cursor freezing, nothing moving etc. The kernel would still be fine so I could ssh in and kill X, which would be running at 99% CPU usage.

Certain things seemed to trigger it, e.g. loading up OpenOffice would guarantee a lock-up.

So yes, hardware RENDER acceleration isn't really there at the moment. I expect this has something to do with the poor results the Rasterman got.

Re:Not enough details

[BenjyD]

It appears to be fixed in 4496, the latest version of the drivers. 4363 would crash every few minutes or so, but 4496 is very stable. Still slower than 3123 for 2D stuff though.

Re:Works nice and fast for me

[b-pot]

You need the Xrender library/header files. If you are using debian unstable: apt-get install libxrender-dev

I get different results - hardware is MUCH faster

[Anonymous Coward]

On my linux/itanium system (using NVIDIA's 1.0.4431/IA64 driver), xrender is always much faster than imlib. Here are the reults:

Test: Test Xrender doing non-scaled Over blends
Time: 0.085 sec.
Test: Test Xrender (offscreen) doing non-scaled Over blends
Time: 0.095 sec.
Test: Test Imlib2 doing non-scaled Over blends
Time: 4.893 sec.
Test: Test Xrender doing 1/2 scaled Over blends
Time: 0.028 sec.
Test: Test Xrender (offscreen) doing 1/2 scaled Over blends
Time: 0.033 sec.
Test: Test Imlib2 doing 1/2 scaled Over blends
Time: 1.344 sec.
Test: Test Xrender doing 2* smooth scaled Over blends
Time: 0.328 sec.
Test: Test Xrender (offscreen) doing 2* smooth scaled Over blends
Time: 0.370 sec.
Test: Test Imlib2 doing 2* smooth scaled Over blends
Time: 28.058 sec.
Test: Test Xrender doing 2* nearest scaled Over blends
Time: 0.323 sec.
Test: Test Xrender (offscreen) doing 2* nearest scaled Over blends
Time: 0.370 sec.
Test: Test Imlib2 doing 2* nearest scaled Over blends
Time: 20.745 sec.
Test: Test Xrender doing general nearest scaled Over blends
Time: 0.780 sec.
Test: Test Xrender (offscreen) doing general nearest scaled Over blends
Time: 0.855 sec.
Test: Test Imlib2 doing general nearest scaled Over blends
Time: 45.613 sec.
Test: Test Xrender doing general smooth scaled Over blends
Time: 0.611 sec.
Test: Test Xrender (offscreen) doing general smooth scaled Over blends
Time: 0.849 sec.
Test: Test Imlib2 doing general smooth scaled Over blends
Time: 74.811 sec.

I ran the benchmark with RenderAccel true

[Sits]

And the results were pretty much the same. Using render was several magnitudes slower on tests 2 - 7. I have a GeForce1 with 1.0.4349 nvidia driver and haven't had the same trouble others have with this option on so I run with this extension on all the time.

Here are the results for the interested:

Available XRENDER filters:
nearest
bilinear
fast
good
best
Set up...
*** ROUND 1 ***

Test: Test Xrender doing non-scaled Over blends Time: 0.190 sec.

Test: Test Xrender (offscreen) doing non-scaled Over blends Time: 0.303 sec.

Test: Test Imlib2 doing non-scaled Over blends Time: 0.697 sec.

*** ROUND 2 ***

Test: Test Xrender doing 1/2 scaled Over blends Time: 10.347 sec.

Test: Test Xrender (offscreen) doing 1/2 scaled Over blends Time: 10.231 sec.

Test: Test Imlib2 doing 1/2 scaled Over blends Time: 0.315 sec.

*** ROUND 3 ***

Test: Test Xrender doing 2* smooth scaled Over blends Time: 207.028 sec.

Test: Test Xrender (offscreen) doing 2* smooth scaled Over blends Time: 205.275 sec.

Test: Test Imlib2 doing 2* smooth scaled Over blends Time: 5.695 sec.

*** ROUND 4 ***

Test: Test Xrender doing 2* nearest scaled Over blends Time: 164.460 sec.

Test: Test Xrender (offscreen) doing 2* nearest scaled Over blends Time: 166.281 sec.

Test: Test Imlib2 doing 2* nearest scaled Over blends Time: 4.119 sec.

*** ROUND 6 ***

Test: Test Xrender doing general nearest scaled Over blends Time: 313.187 sec.

Test: Test Xrender (offscreen) doing general nearest scaled Over blends Time: 310.261 sec.

Test: Test Imlib2 doing general nearest scaled Over blends Time: 11.444 sec.

*** ROUND 7 ***

Test: Test Xrender doing general smooth scaled Over blends Time: 477.511 sec.

Test: Test Xrender (offscreen) doing general smooth scaled Over blends Time: 474.695 sec.

Test: Test Imlib2 doing general smooth scaled Over blends Time: 17.290 sec.

(reformatted to get past the lameness filter)

Re:2D acceleration using OpenGL?

[Mr Z]

I have a dual Athlon MP 2600 running w/ an nVidia GeForce 4 MX440. Here's what I get for 1 through 4 glxgears:

1. ~7400 frames / 5 seconds
2. ~3000 frames / 5 seconds
3. ~1500 frames / 5 seconds
4. ~1300 frames / 5 seconds

The fall-off is slightly more harsh than linear for 1 through 3, probably synchronization overhead. 4 seems to get faster in terms of total frame rate across all four instances. 2*3000 == 6000, 3*1500 = 4500, 4*1300 = 5200(!)

--Joe

Re:is this the man who said that "Windows has won"

[Simon Kongshoj]

He said that over a year ago, however, when desktop Linux wasn't looking so hot. A large part of his point was that the desktop itself would be going away in the future, except as hackers' and enthusiasts' systems. In fact, he went on to state that if this is the case, Linux has a huge advantage over Windows, since Linux is not nearly as tied into the desktop as Windows is, and will have an easier time adapting to such a setting. So he ported his canvas library to run on embedded as well, without axing it for the desktop. Sounds to me like a wholly reasonable thing to do.

Re:One word:

[flynn_nrg]

The file manager, for example, used resizable icons. Moving a slider would make the icons bigger or smaller. Those were definitely vector graphics. I'm not 100% sure, but I'd bet those were opengl objects.

About grandparent's comment, yes, SGI created IrisGL first, then moved onto OpenGL when they opened up the specs, and had a glue library for compatibility with old apps, called Igloo (IrisGL on OpenGL)

Btw, I've tried rasterman's test on my ancient Riva TNT card and software rendering is indeed a lot faster.

Building E17 from CVS right now :)

Re:The results are not obviously broken

[Yokaze]

> I'm going to take a stab at explaining the results by suggesting that the hardware is probably performing the scaling operations each and every time, while imlib2 caches the results (or something).

Well, you have the means at hand to confirm it.

A quick glance reveals, no, the result is not cached in the sense you probably assume.
The Imlib2 scales and fitlers the image in each of the REPS iterations.

Re:It's wrong to use 3D functionality for 2D graph

[Elm Tree]

Unless I'm mistaken, XRender is utilizing the 2D acceleration features of a graphics card for scaling, alpha blending, anti-aliasing, etc. It's not trying to do 2D graphics over 3D. Although if you think linux shouldn't be doing that then you really shoulod look at Microsoft, they're moving to an entirely 3D desktop for longhorn.

Re:It's RIGHT to use 3D functionality for 2D graph

[rmlane]

On vaugley modern hardware the 3D path is so much faster than the 2D path that it ends up being significantly faster to use the 3D path to render your desktop if your desktop is at all complicated (not a dozen mono xterms).

This ends up being even more true if you do any sort of complex compositing (eg: alpha blending, hardware accelerated mpeg / video, openGL windows, etc, etc). Enlightenment uses alpha channels, it would be fater to composite in hardware than software. These sorts of operations are not accelerated at all on the 2d path, and have to be done in software.

Go check out Quartz Extreme at http://www.apple.com/macosx/jaguar/quartzextreme.h tml (excuse the space in html).

Having used Xfree86 and Quartz extreme on the same graphics hardware, I can tell you there's no comparison. Quartz is much faster and much more capable.

Re:One word:

[be-fan]

Arg. Not again. -5 "dis"informative. Quartz "Extreme" does not accelerate any actual rendering! According to Apple's very on Siggraph presentation, all 2D rendering is still done via software. Only final window *compositing* (doing the alpha blend between all the windows) and window-level effects (like the genie effect) are done via OpenGL.

Re:2D acceleration using OpenGL?

[Rabid Penguin]

Yes, and in the end, there is a good chance this will be an option for Enlightenment. Raster has been hard at work on an image layout/animation engine for theming borders and backgrounds, and I would be willing to bet once the OpenGL evas backend is in place, there will be an option to use it for animated backgrounds. Borders will most likely be software only until a hardware solution is found that provides increased performance for small drawing areas.

Quartz Extreme in a few words

[The Ego]

Apple's OSX does all rendering through Quartz, (as PDFs) which is accelerated by OpenGL, and called QuartzExtreme.

That's not accurate. Quartz is really made of two parts: Quartz 2D and the Quartz Compositor.

The Quartz Compositor is reponsible for compositing all the layers (desktop, windows, layers inside windows) on-screen. It offers Porter-Duff compositing, which was developped at Pixar more than 15 years ago. See this post [google.com] from Mike Paquette for details. Mr Paquette is one of the main developpers of Quartz. Quartz Extreme is "simply" an OpenGL implementation of Porter-Duff compositing and modern graphic cards offer the primitives needed to do that very efficiently.

The Quartz 2D layer is what offers drawing primitives following the Postscript drawing model. The same drawing model is used with PDF (no surprise), Java2D and SVG (and Microsoft's GDI+ ?). This part is not HW accelerated. I am sure Apple is working on it, but it wouldn't surprise me if new HW will be required to make this possible. There is a strong incentive for card manufacturers to offer acceleration, since Longhorn is supposed to use GDI+ extensively. I doubt that such acceleration will fit in the traditionnal OpenGL/Direct3D rendering pipeline.

The Apple JVM team implemented HW accelerated Java2D drawing in their 1.3.1 JVM. Their 1.4 JVM doesn't offer it (1.4.1 was a massive rewrite for them, 1.3.1 was more of a quick port to OS-X using some of their "old" carbon code). There were quite a few problems when HW acceleration was used. I hope they can and will wait for a system-wide Quartz-2D HW acceleration, it seems ludicrous to have the JVM team spend resources on an effort that will be wasted once Quartz2D is accelerated.

See Apple Marketing page [apple.com], another post from Mike Paquette [google.com], and the presentation from Apple at SIGgraph about Quartz Extreme and OpenGL [opengl.org].

If that post doesn't end-up rated +5 informative, I don't know what will ! :-)

Re:2D acceleration using OpenGL?

[Animats]

So basically it scales almost perfectly with the number of open windows.

Which means it's broken. All the windows should run at full speed until the graphics pipeline saturates.

There are several problems. First, make sure that you're not running with "wait for VBLANK" off. There's a stupid overclocker mania for running the graphics system faster than the display can refresh. This leads to high, meaningless frame rates, and to lower system performance because the useless redraws are using up all the CPU time.

Once you're past that, the issues are more fundamental.

The real problem is that OpenGL is double-buffered, but most windowing systems don't understand double-buffering or frame-synchronous drawing very well. Even OpenGL has no notion of time. But this could be fixed.

Usually, each app draws into the back buffer, then makes the OpenGL call to swap the buffers. This blocks the app (older NVidia drivers for Windows spin-locked, but I got them to fix that), but worse, it typically locks up the OpenGL subsystem until the frame ends and the buffer swap occurs. Implementations like that can only draw one window per frame time, obviously.

What ought to happen is that a request for a buffer swap should schedule a buffer swap for the next frame cycle, block the app, then let other apps get in their draw time. At the end of the frame, when everybody is done drawing, all windows get buffer swapped, and all the apps stuck in the OpenGL buffer swap call then unblock simultaneously. That way, multiple OpenGL apps running in different windows all run at full frame rate, until the scene complexity hits the limits of the graphics hardware.

Part of the problem is that X and OpenGL are such drastically different architectures that making them play well together is tough. X assumes a network-centric model; OpenGL assumes you're local. X expects a weak terminal; OpenGL needs good graphics acceleration. X is built around a windowing concept; OpenGL doesn't know about windows. X and OpenGL are defined by different organizations.

Microsoft is pulling this together in the Windows world, but it's all done with Microsoft APIs, and, recently, undocumented hardware that favors those APIs.