The Underlying KWin Improvements In KDE 4.7

[phoronix]

Phoronix: The Underlying KWin Improvements In KDE 4.7

Now that the first KDE SC 4.7 beta is available, Martin Gräßlin, the lead developer of the KWin, has blogged about some of the underlying improvements made to the compositing window manager for KDE during this development cycle. Of course, most Phoronix graphics junkies will already know what's changed based upon previous articles, but here's an overview for those not caught up to speed...

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

[NSLW]

For anyone still (unfortunately) living in an OpenGL 1.x world, the OpenGL 2 / GLSL shaders can be disabled until you buy new hardware.

For anyone wishing to use nouveau on OpenGL 2 capable hardware.

[d2kx]

Awesome improvements! KDE 4.7 bundled with Qt 4.8 should give a very nice performance boost over the current offerings.

[Maxim Levitsky]

For anyone wishing to use nouveau on OpenGL 2 capable hardware.

Don't troll please!

"OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NV86
OpenGL version string: 2.1 Mesa 7.11-devel (git-462d405)
OpenGL shading language version string: 1.20
"

All Linux games run fine here, and even Unegine demos run (with glitches though)

[NSLW]

Don't troll please!

Don't make false judgements please!

Returning to the topic, my nouveau on Fedora 15 advertises only OpenGL 1.3 for NV9x hardware.

[elanthis]

Why is a flag necessary to turn of compositing?

I'm confused why the window manager can't do this automatically if there's a top-level full-screen window at the top of the window stack, and automatically turn compositing back on whenever that condition ends (so volume control overlays and stuff still work without glitches/flickering even when a full-screen GL app is running).

[GreatEmerald]

Why is a flag necessary to turn of compositing?

I'm confused why the window manager can't do this automatically if there's a top-level full-screen window at the top of the window stack, and automatically turn compositing back on whenever that condition ends (so volume control overlays and stuff still work without glitches/flickering even when a full-screen GL app is running).

Exactly my thoughts... Is it so difficult to detect fullscreen programs automatically?

[TheBlackCat]

X11 doesn't really have fullscreen windows, they have to be faked.

[Wingfeather]

What i don't understand is WHY there is a need to turn off compositing for fullscreen apps. It sounds like a terrible hack. If all running apps can draw their contents to pixmaps, and the compositor can arrange them all on the screen, what difference should it make if one happens to be really big? I don't see why there is such 'overhead'.

Is this simply a limitation of the current implementation or a real logical issue?

[kayosiii]

It just removes a level of indirection and can free up resources that aren't used in case where a fullscreen application is running (remember when compositing that other apps will be rendering themselves to pixmaps - you can get rid of those if you turn compositing off).

This can be helpful if latency is important to the application or the application pushes the hardware to it's limits.