A Performance Overhaul Of KDE's KWin

[Joe Sixpack]

I think the consequences of unredirecting are too much of an engineering headache to make it worth the performance gain. When you unredirect a window, you either have to disable compositing entirely, or else figure out a way to work around the limitations of unredirecting. For instance, what do you do if a modal dialog window pops up in front of the fullscreen app? Plenty of "fullscreen" applications would want this; for instance, for generating a dropdown menu in many widget toolkits, they create a new XWindow.

No. Unredirection gives me headaches just thinking about it. The point of a compositor is that everything is redirected. What we need is to work on reducing the overhead of the compositor, both on the driver side and the compositor side. If the redirection can be made cheaper, we'll be in good shape.

Look at how Windows handles it. Their equivalent of "redirection" in Aero is essentially uninterrupted, even when playing a full-screen 3d game. But the overhead isn't enough that you would get noticeably higher FPS if you disable Aero. So most games just let Aero run. There's too much flickering and flashing when enabling/disabling the compositor anyway (and that goes for Windows and Linux desktops alike).

Unredirection is a kludge that works around a present-day perceived performance hit by going back to the old days of non-redirected windows. Mixing and matching redirected and unredirected windows is nasty. And if we'd just give our software and hardware some time to mature, the performance issue will disappear, and we'll look back in hindsight and wonder why we cared about that unredirection crap anyway, and wish we could eliminate it.

In the not-too-distant future, R900-class hardware will be as old as R300 looks today. Let's plan for that by figuring out a way to make everybody happy with redirection, rather than trying to workaround a bottleneck in present-day hardware and software paths.

First you pointed out something that Windows does better than Linux, then you suggested we think forward instead of making sure every DE shipped with every distro maintains support for old hardware. You effectively committed forum suicide twice in a single post.

All jokes aside, I completely agree.

[_txf_]

First you pointed out something that Windows does better than Linux, then you suggested we think forward instead of making sure every DE shipped with every distro maintains support for old hardware. You effectively committed forum suicide twice in a single post.

All jokes aside, I completely agree.

I don't disagree that unredirection is a horrible kludge, but, on linux where the gfx stack is old, crufty and non-performant it is necessary to get decent performance out of ogl apps and videos even if notifications etc flicker the screen.

[Maxjen]

Good for Martin for properly digging into this. It seems that actually rendering at 60fps is going out of style, at least partly based on the ignorant notion that because films are acceptable at 24fps, anything higher in any context must be overkill. It's good to see someone having it as a goal, especially for a (mostly) 2D app where the difference is more likely to be noticeable.

Exactly. This is probably one reason why enlightenment feels so fast. (at least rasterman seems to be aware of this)

It's also interesting that Avatar 2 will likely be shot at 60 frames per second.

[BlackStar]

I don't disagree that unredirection is a horrible kludge, but, on linux where the gfx stack is old, crufty and non-performant it is necessary to get decent performance out of ogl apps and videos even if notifications etc flicker the screen.

Or you could, you know, just use fglrx which appears to work faster with an opengl compositor than without. At least according to the Phoronix benchmarks.

[lpjhjdh]

I can't use fglrx because I have switchable graphics that I can't disable and no luck with the latest closed-source driver.

[BlackStar]

And I can't use fglrx because it kills suspend (and can't use the open-source drivers because they kill the battery). Annoying, isn't it?

[RealNC]

You're just trolling. The problems you describe don't exist. I know because I saw screenshots of Linux desktops with AMD cards that were actually able to display a desktop.

[BlackStar]

You're just trolling. The problems you describe don't exist. I know because I saw screenshots of Linux desktops with AMD cards that were actually able to display a desktop.

No, *you* are just *trolling*, because I *have* another screenshot that *proves* the *opposite* of what you wrote. Brace for impact.

Here it comes!

(Click for a larger version)



See? It's obvious that fglrx is not working at all.

[rohcQaH]

See? It's obvious that fglrx is not working at all.

Have you tried switching your monitor on?

KWin + fglrx seems to alternate between "working" and "non-working" depending on the fglrx version and kwin version. Upgrading either is likely to change the specific set of problems you encounter.


What really irks me is synchronizing issues with urxvt. urxvt outputs new text, but kwin only updates half of the changes, forcing me to alt-tab twice to properly redraw the window. Haven't figured out who's at fault: KWin, urxvt or xf86-video-ati. :/

[BlackStar]

Have you tried switching your monitor on?

Damn, should have thought about that. Now it works!