That is not true. Windows do the same kind of thing as kwin, i.e. having this static thumbnail 'screenshot' of the window.
Originally Posted by RealNC
Though, windows is able to show the thumbnail, even though you haven't seen the window yet (app starting minimized). That is something kwin cannot do AFAIK.
The only useful thing in those Windows thumbnails is how they show download progress (in supporting apps) :P
Where does this piece of information come from? Is it based on something remotely tangible such as numbers of bug reports for windows games vs window managers or is it just an assumption? I was expecting anything but games running through wine.
Originally Posted by marek
I'd like to see some hard facts supporting this, instead of just the opinion of the most vocal people. I for one consider the added usability of a composited desktop (which is not just "eye candy") much more important for me than game support.
Originally Posted by marek
And even in game players, I suspect many of them would still like to have the composited desktop.
I tend to believe that this opinion is based more on the personal preference of the developper than on any "reality", which is OK in my opinion, since he's the guy working on the code. But this should be assumed as a personal choice and not claimed as being the "reality", until at least this claim is supported by real valid statistical numbers.
I have seen a lot of similar comments on IRC over the last couple of years. That said, opinions vary widely between individual users - for some running a modern composited desktop is the clear priority, but a lot of others cheerfully switch off compositing if it gives them even a hint of additional performance or stability. It's hard enough to get two users to agree on priorities, but fortunately the same mix of priorities exists in the driver community.
Originally Posted by rvdboom
One thing worth noting is that we are talking about a community, not a hive brain. You are going to see different views of priorities within the community, and developers are going to tend to work on their own priorities. Given the wide variation in user priorities I think that works better than having everyone restricted to working on the priorities set by a community dictator.
There was a big push a couple of years ago to get the driver stack to the point where it could run a composited desktop out of the box, but for better or for worse "composited desktop" meant "Compiz" at the time - partly because of distro defaults, and partly because the level of GL support required for Compiz was lower and more achievable than the level required for KWin support.
Stinkin' edit limit...
Sorry, by "similar" I meant "similar to what Marek said", ie that supporting <Windows game> was more important than supporting <compositor>.
The real challenge here, I think, will be getting past the wrong perceptions that were formed, and unfortunate statements that were made, during the initial period when the open driver developers were in the process of adding GL 2.x support. For most apps, and most users, exposing the new work-in-process functionality was the best approach because it allowed users to immediately take advantage of the new capabilities and to run applications (yeah, games ) which previously would not work, but for the case where applications implemented multiple code paths and selected a code path based on what the driver exposed there was a real risk of regressions. We saw the same thing with one of the Quake engines IIRC, but once the issue was understood it seemed to be accepted as a temporary "cost of progress".
KWin seemed to be one of the few cases where there was both a real regression (as a result of detecting new GL capabilities and attempting to use them) without an easy workaround for users (since KWin started automatically so problems were obvious and hard to avoid, whereas games were manually started by the user so in the worst case they could simply "not run the game" while they figured out what the problem was.
I don't think a real solution for this has been found, in the sense that (a) exposing work-in-process capabilities had bad side effects in very specific cases (KWin), while (b) not exposing those WIP capabilities had bad side effects in many other cases (users would lose the ability to run a number of other apps). Upstream testing might have identified the problem a bit earlier, but even after a year I don't think we have a good solution identified other than white/blacklisting by the distros or completing the development effort (which has pretty much been done AFAIK).
It probably is fair to say that more work is needed in terms of dealing with apps which (a) auto-detect driver capabilities and take different code paths depending on what they find, and (b) are run automatically at startup so that the impact of problems is serious for end users.
In the case my post was not clear about that, I understand the above and totally agree with that. I just wanted to point out that there doesn't seem to be such definite "reality" as Marek says, and your posts seem to describe the whole situation in that aspect pretty well.
Originally Posted by bridgman
As a matter of fact, my laptop with a RV420 (I believe) chip started running KWin 4.6 composited desktop in OpenGL with my last week-end's git pull of libdrm, mesa and xf86-video-ati, so indeed, things are moving in the right direction. Congrats to the devs.
It's because some idiots in Red Hat and Novell think gnome can compete with Windows and OS X. Or they simply don't care about desktop.
Originally Posted by RealNC
Or maybe there isn't universal agreement that expanding and enriching the desktop experience is the top priority in the first place...
Originally Posted by kraftman
If anything, the trend seems to be towards simplification and bringing the mobile user experience to the desktop, at least that's what I am seeing.
Tags for this Thread