KDE's Plasma To Be Reworked, Use More OpenGL

[Joe Sixpack]

Much like how I can no longer turn on compositing without causing my desktop to flicker whenever I open the Application Launcher. As of 4.5.

In fact it's a general trend I've faced in the progress of open source software: 3 steps forward (bug fixes and new features), 2 steps back (bad, sometimes critical regressions).

http://blog.martin-graesslin.com/blog/2010/09/driver-dilemma-in-kde-workspaces-4-5/

When I see these problems I think: "it looks like we are the first one to actually use the drivers". And then I start to think about it and realize: yes we are. Compiz does not yet use GLSL (Compiz?s Blur effect is written in GPU assembler. KWin blur also has an assembler part which is a fallback in case the driver does not claim support for GLSL), so we are probably the first ones to use these driver capabilities in a real world application. Now why are we using something that new? Because it is quite old: this is OpenGL 2 we are speaking about, a standard specified in 2004! Btw. Microsoft made use of blur by default when they introduced Vista, that was in 2006. So we are talking about functionality specified since six years and used by default by our competition for four years. Oh and please note: the same hardware runs fine in Vista or Windows 7 ? at least that?s what we can see from the bug reports.

As it's been stated in a few other places: most of the issues stem from graphic drivers claiming functionality that they don't currently support. Like anything else in software, the first programs that utilize features will always expose bugs.

[marek]

I agree that the KDE guys blundered with the KWin 4.5.

Developers make bugs, no surprise, stuff like that happens, it's inevitable, but fixable. Their biggest mistake was they decided to be childish and put the blame on somebody else.

[marek]

As it's been stated in a few other places: most of the issues stem from graphic drivers claiming functionality that they don't currently support.

That's non-sense. We've been through this many times on this board before. No so-called "GL2 hardware" supports GL2 except for NV40, and both ATI and NVIDIA have given a list of features you should not use with their GL2 drivers. Every GL2 game developer had to follow that. Also the issue the blogpost is talking about is not about faking features, it was just a bug in Mesa they did not want to report. How brave.

That blogpost is simply full of demagogism.

[Joe Sixpack]

That's non-sense. We've been through this many times on this board before. No so-called "GL2 hardware" supports GL2 except for NV40, and both ATI and NVIDIA have given a list of features you should not use with their GL2 drivers. Every GL2 game developer had to follow that. Also the issue the blogpost is talking about is not about faking features, it was just a bug in Mesa they did not want to report. How brave.

That blogpost is simply full of demagogism.

That's interesting, because Marco Martin claims the exact opposite:

...we use all the best the system has to offer, we report problems in the components that we use, their developers are aware of that.
if the problem is still there after so many years is an unfortunate thing, it will eventually be fixed but we simply can?t stagnate because parts of the stack can?t keep up

I was just simply stating the accusation - and it's an accusation I've read on a number of forums and blogs. Even if they didn't want to report bugs like he claimed they do, how does that change anything? The accusation was that bugs in graphic drivers are causing problems with Kwin. Doesn't your admission prove that?

Also, could you point me to the list of features ATI and Nvidia said not to use with their GL2 drivers? (Just for my own curiosity...)

[bridgman]

The general consensus seems to be that the non-optional portion of the GL ES 2.0 subset seems to be a good target, in the sense that it offers a better match to real-world hardware than the GL 2.0 spec.

The problem is that the GL 2.0 spec came out *after* the hardware that *almost* supports it was designed, so there's a lot of "almost but not quite" support in the 2005-ishhardware.

[ChrisXY]

You've got no luck or there's something seriously messed up. What graphic drivers are there?

There is the nvidia blob.

What drivers?

At home xf86-video-ati-git but I also tried on my eee with xf86-video-intel.

You had seriously messed up system I guess, the same as me, but when I was running the latest 'stable' Gnome release on Fedora.

I deleted ~/.kde4 before and used a vanilla KDE as Archlinux uses nearly always vanilla software.

[kraftman]

I deleted ~/.kde4 before and used a vanilla KDE as Archlinux uses nearly always vanilla software.

You could try current Arch with newer dbus shipped. It was causing problems on many configurations, but I was lucky.

[V!NCENT]

Developers make bugs, no surprise, stuff like that happens, it's inevitable, but fixable. Their biggest mistake was they decided to be childish and put the blame on somebody else.

Excuse me, bureau of the graphics driver exposes incomplete andere buggy features, then whose 'fault' is it when theater crashes? Oops. ..

[V!NCENT]

Stupid android ti9...

Excuse me but if the graphics drivers expose unstable, incomplete and buggy features, then if these crash it's motor KDE's faculteit. KDE only has a correct implementation whereas the graphics drivers do not work correctly...

[V!NCENT]

Stupid android ti9...

Excuse me but if the graphics drivers expose unstable, incomplete and buggy features, then if these crash it's motor KDE's faculteit. KDE only has a correct implementation whereas the graphics drivers do not work correctly...