More Details On The OpenGL Situation In KDE's KWin

[KAMiKAZOW]

So when someone develops a fscking Window manager with compositing, he needs to check it with all major implementations of graphic stacks.

No, volunteer developers do not need to do that. Plain fact. And as long as you don't pay him any money, you have absolutely no right at all to demand that.

And he needs to communicate all driver problems to driver devs during the beta phase of the project,

No, he does not. He doesn't even need to develop anything at all. He's a volunteer.

What you are demanding is the duty of commercial software vendors, not voluntary ones. And since Canonical, Mandriva, Red Hat, Novell, etc. all make money from Martin's voluntary work, it's their responsibility – either by communicating or by fixing the broken drivers.

and if the devs do not solve the problem in time, take measures in order to deliver a stable product.

No, it's not the duty of voluntary coders to work around bugs that have been introduced in drivers produced by multi-billion dollar enterprises.

And then they wonder why KDE sucks...

KDE is an organization. If you don't like that organization, OK, but this has nothing to do with the topic here.

Let's see now, who is spreading FUD now?

You. All the time.

KDE's marketshare will continue to shrink

Any facts to back your claim up? Last time I checked KDE software was used by roughly 100 million users (just an estimate of course since there is no way to confirm the actual number of KDE users, so I wonder where you got your data from... Phoronix Test Suite benchmark? – Run it to find out how many users one piece of software has? Your benchmarks are so stupid at times, that scenario is not unlikely)

In 5 years from now KDE will only be used by its devs...

That's OK. KDE's developer base is growing constantly. If in 5 years all of KDE's ~100 million users are KDE developers, the future is certainly bright.

My dbus is up-to-date, unlike KDE fanbois like you i use a real distro...ArchLinux.

One of the most unstable distributions out there. Pass.

If you believe KDE is less bloated, then you are wasting everyone's time here... Get back to school.

KDE has only a single employee. How can an organization with only one employee be bloated?
If you wrote. Orace is bloated, I might have agreed with you but KDE? No.

[MaestroMaus]

Just checking in to see which troll has the upper hand in this flamewar.

That's OK. KDE's developer base is growing constantly. If in 5 years all of KDE's ~100 million users are KDE developers, the future is certainly bright.

This has got to be my most favorite comment.

"What do you mean, out of touch with reality?"

*snicker

[Ian_M]

Yes, he's a volunteer so he doesn't have to test his code with any hardware at all if he doesn't want to. And the rest of the world doesn't have to use his software or care if it is incompatible with their drivers. So what exactly are we arguing about here?

[BlackStar]

The blobs had access to a fairly sophisticated shader compiler that could deal with shader substitution, injection of code to get around hardware limitations, *and* (on a good day but not all days) funky things like Wine hard-allocating the maximum possible number of resources (which of course wreaks havoc if any workaround shader code is added by the driver). Even that code couldn't deal with all of the potential variables.

The older "pretty much everything works" hardware is exactly the "not quite OpenGL 2.x but everyone expects it anyways" hardware I talked about in (1). That is the worst case scenario for OpenGL support, since the DX and OpenGL specs diverged the most at that point (both in time and in granularity) and most of the hardware was designed around DX specs since the corresponding OpenGL specs did not exist.

Yes, but does kwin use those GL2.1 features that are not supported by the silicon? That was my point.

I actually took the time to check the blur shader in kwin and it is a straightforward, semi-optimized implementation of a gaussian kernel. No loops, no flow control, explicit checks for resource limits (varyings/uniforms) - even the old Mesa GLSL compiler should be able to cope with this. There's an ARB program version with even lower resource limits.

I have checked a few other effects and nothing seems out of order: typical texture parameters (linear/clamp-to-edge, no unsupported mirroring/repeat modes), typical, some FBO and CopyTexSubImage usage (Mesa historically had problems with those but they should be nice and fast now). The lanczos filter was probably too much for R300c/g but the new work on loop unrolling should fix that.

What I am trying to say is that the code doesn't seem to use OpenGL in a way not supported by the hardware. Obviously, I haven't (and won't) check the whole thing but from what I've seen it looks like pretty ordinary stuff. It doesn't seem to do anything, say, Nexuiz doesn't do either (Nexuiz being much more complex).

[smitty3268]

Yes, but does kwin use those GL2.1 features that are not supported by the silicon? That was my point.

I actually took the time to check the blur shader in kwin and it is a straightforward, semi-optimized implementation of a gaussian kernel. No loops, no flow control, explicit checks for resource limits (varyings/uniforms) - even the old Mesa GLSL compiler should be able to cope with this. There's an ARB program version with even lower resource limits.

I have checked a few other effects and nothing seems out of order: typical texture parameters (linear/clamp-to-edge, no unsupported mirroring/repeat modes), typical, some FBO and CopyTexSubImage usage (Mesa historically had problems with those but they should be nice and fast now). The lanczos filter was probably too much for R300c/g but the new work on loop unrolling should fix that.

What I am trying to say is that the code doesn't seem to use OpenGL in a way not supported by the hardware. Obviously, I haven't (and won't) check the whole thing but from what I've seen it looks like pretty ordinary stuff. It doesn't seem to do anything, say, Nexuiz doesn't do either (Nexuiz being much more complex).

The taskbar thumbnails apparently did, and one of the KWin devs is rewriting it into a more Mesa-friendly form for 4.5.2.

https://bugs.freedesktop.org/show_bug.cgi?id=30007

Blur bug is here: https://bugs.freedesktop.org/show_bug.cgi?id=30152, with no solid leads yet.

[BlackStar]

The taskbar thumbnails apparently did, and one of the KWin devs is rewriting it into a more Mesa-friendly form for 4.5.2.

https://bugs.freedesktop.org/show_bug.cgi?id=30007

Blur bug is here: https://bugs.freedesktop.org/show_bug.cgi?id=30152, with no solid leads yet.

Yeah, the change has been committed to kwin trunk (which is why I didn't mention this at all).

[kraftman]

Okay what about freeze and hangs with konqueror and other kde apps? Occasionally when I e.g. type in an address into konquerors address-bar, it sometimes hangs for about 6 sec, before it works normally again.

No idea. However, there's a chance it's also related to composition somehow, because even K menu is slugghish on your box. The best you can do is probably try compiz and check if Konqueror some other apps behave the same.

[kraftman]

Do you not recall Neary's census from a month ago, or so? IIRC, 37% is the number of volunteers (the single largest contribution block), while the remainder were from companies (hence, unlikely to be volunteers).
To argue that Gnome is less corporate seems a strange thing to attempt...

I was looking for your link, but I didn't find it. I'm not arguing Gnome is less corporate, because it's not of course.

"So you want to tell me that Gnome tries to "compete" using only a small number of volunteer devs? Btw. how did you figure out such stupid conclusions? "

This was to show someones argument was stupid. There are very large numbers of volunteers working on both projects and someone said KDE tries to innovate the desktop using only a small number of volunteers which is just not true.

Metacity supports compositing. This is trivial to look up. This has been around for years...
kraftman, didn't we have this discussion awhile ago?

Yes, but you have to edit some configuration to enable it. And this is something like XFCE offers right? I was talking about compositions like Kwin, Compiz and Win7 offers.

[liam]

I was looking for your link, but I didn't find it. I'm not arguing Gnome is less corporate, because it's not of course.

"So you want to tell me that Gnome tries to "compete" using only a small number of volunteer devs? Btw. how did you figure out such stupid conclusions? "

This was to show someones argument was stupid. There are very large numbers of volunteers working on both projects and someone said KDE tries to innovate the desktop using only a small number of volunteers which is just not true.



Yes, but you have to edit some configuration to enable it. And this is something like XFCE offers right? I was talking about compositions like Kwin, Compiz and Win7 offers.

..now you must give him your email address http://www.neary-consulting.com/inde.../gnome-census/
Regarding the KDE commiters, it is an interesting discussion to have. I haven't been able to find solid figures as to who actually contributes to the project. I assume it is mostly volunteers (basically the exact opposite of the Gnome profile).

Lastly metacity, for me, has defaulted to compositing for the last 4 or 5 releases, and changing that is easy, especially for one used to KDE Metacity uses the compositing to increase usability exclusively (hence no wobbly wins), and Mutter requires this feature as well even though it too uses no bling. Regardless, they both use compositing, and, fundamentally, are no different than KWin/Compiz... except they work

[pingufunkybeat]

Compositing has been available for pretty much all window managers since xcompmgr. This is nothing new.

However, any desktop effects related to compositing -- and this includes not only wobbly windows and similar eye-candy, but also proper thumbnails, previews, tiling, exposee, smooth minimize animations, and similar stuff -- needs to be supported by the window manager itself.

This sort of stuff will be a part of Mutter, when it's out, just like it's been a part of Compiz and KWin for many years now.