KDE SC 4.7.0 Officially Released

[BenderRodriguez]

There are always two sides on the stick

Some would complain that they introduce new stuff instead of stabilizing it, the others would complaing that they don't introduce new stuff (but you never hear them complain that it is stable ).

I think KDE has come to the point where it is mature and quite stable. The good thing is that they are not going to make some instabilities when moving to Qt 5 and ultimately to KDE 5 so there will be no 4.0 experiences

[deanjo]

perhaps I'm simply expecting too much from every release?

I think this is the case. Not every release of a product has to have more "whiz bang" end user visible changes.

[deanjo]

glxgears is not a benchmark glxgears is not a benchmark glxgears is not a benchmark
glxgears is not a benchmark glxgears is not a benchmark glxgears is not a benchmark
glxgears is not a benchmark glxgears is not a benchmark glxgears is not a benchmark

I could never understand why they got rid of the -glxgearsisnotabenchmark switch

[Nevertime]

I only upgraded to kde 4.7 yesterday but compared to previous upgrades there seems to be a lack of noticeable refinements to how you actuality interact with the gui.

Is this a sign they've got it close to how they ultimately want it to work or a lack of new ideas? Maybe I'm missing something or perhaps I'm simply expecting too much from every release? A new version of kde 4 does typically deliver noticeable improvements.

[BlackStar]

Very, very marginally. I'm tempted to say it's such a bad benchmark it's completely useless, but that is a big enough drop

6000 fps == 0.000167 seconds / frame
2500 fps == 0.000400 seconds / frame

This is a differencee of 233 μs, which is closer to "trivial" than "big". The kernel sneezes and you get larger fluctuations than that.

glxgears is not a benchmark glxgears is not a benchmark glxgears is not a benchmark
glxgears is not a benchmark glxgears is not a benchmark glxgears is not a benchmark
glxgears is not a benchmark glxgears is not a benchmark glxgears is not a benchmark



(Even worse, there is no "upstream" for glxgears, so you cannot fix it to report proper frametimes. Sucks.)

[smitty3268]

Not quite. glxgears is running inside the compositor, so it's affected by its performance. So from that perspective, it's useful as a benchmark.

Very, very marginally. I'm tempted to say it's such a bad benchmark it's completely useless, but that is a big enough drop that I suppose we can probably say something bad MAY be happening. I'd want a lot more evidence, though, before actually claiming it. A glxgears framerate by itself is nothing, it just points out that maybe you should keep looking into other benchmarks to see if there is really something going on or not.

I "downgraded" Mesa to 7.11 RC2. The crash still happens and gbm is still there.

You're right, it looks like it was added June 23 which is longer back than i thought.

[RealNC]

glxgears is not a valid benchmark, even at the best of times. And in this case, it's completely bypassing the EGL/GL ES setup you're running anyway. glxgears

Not quite. glxgears is running inside the compositor, so it's affected by its performance. So from that perspective, it's useful as a benchmark.

Sure, there's a price to pay for using old Mesa versions as well. But I don't think you can complain that a version from git is broken, especially since it's the still somewhat experimental EGL/GL ES functionality that's broken. I think gbm was only checked in a week or so ago, so people not quite on the bleeding edge may have more success.

I "downgraded" Mesa to 7.11 RC2. The crash still happens and gbm is still there.

[smitty3268]

Setting EGL_PLATFORM=x11 allows it work, but now it's even slower! Even glxgears dropped from 6000FPS to 2500FPS.

glxgears is not a valid benchmark, even at the best of times. And in this case, it's completely bypassing the EGL/GL ES setup you're running anyway. glxgears

The real question is how the desktop effects are working, and how normal desktop apps are running on top of it. So far, commenters seem to be pretty universally saying the situation is better, so you seem to be the outlier here.

About the "price to pay" for Mesa git, if I don't use latest Git right now, Flash locks up the system in fullscreen with page flipping enabled. Similar bugs prevented me in the past from using normal releases. There was often some bug that was only fixed in Git.

Sure, there's a price to pay for using old Mesa versions as well. But I don't think you can complain that a version from git is broken, especially since it's the still somewhat experimental EGL/GL ES functionality that's broken. I think gbm was only checked in a week or so ago, so people not quite on the bleeding edge may have more success.

[RealNC]

Both the parent post and the bug you linked to provide a workaround:

Setting EGL_PLATFORM=x11 allows it work, but now it's even slower! Even glxgears dropped from 6000FPS to 2500FPS.

Getting buggy stuff like gbm before it's ready is the price you pay running mesa from git.

Trying with --disable-gbm results in:

configure: error: EGL platform drm needs gbm

About the "price to pay" for Mesa git, if I don't use latest Git right now, Flash locks up the system in fullscreen with page flipping enabled. Similar bugs prevented me in the past from using normal releases. There was often some bug that was only fixed in Git.

[smitty3268]

Screw you, buddy.

https://bugs.kde.org/show_bug.cgi?id=278653

Both the parent post and the bug you linked to provide a workaround:

The bug only occurs with drm platform. With x11 everything should work fine.
A workaround would be
a) Setting EGL_PLATFORM=x11
b) Don't build drm platform, so that x11 is chosen by default.
(--with-egl-platforms=x11 instead of --with-egl-platforms=drm,x11)

Getting buggy stuff like gbm before it's ready is the price you pay running mesa from git.