Announcement

Collapse
No announcement yet.

What Would Be A Win For KWin In KDE

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    The only useful thing in those Windows thumbnails is how they show download progress (in supporting apps) :P

    Comment


    • #22
      Originally posted by marek View Post
      He said that StarCraft 2 is a much much more important user of Mesa/X.Org than KWin and that many people would gladly sacrifice Kwin if they could run SC2 or WoW. AAA games are one of the most important pieces of software for Linux consumers and generally for Linux success on the consumer market, not some desktop eye candy. That's the reality.
      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.

      Comment


      • #23
        Originally posted by marek View Post
        He said that StarCraft 2 is a much much more important user of Mesa/X.Org than KWin and that many people would gladly sacrifice Kwin if they could run SC2 or WoW. AAA games are one of the most important pieces of software for Linux consumers and generally for Linux success on the consumer market, not some desktop eye candy. That's the reality.
        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.
        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.

        Comment


        • #24
          Originally posted by rvdboom View Post
          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.
          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.

          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.
          Test signature

          Comment


          • #25
            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.
            Test signature

            Comment


            • #26
              Originally posted by bridgman View Post
              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.
              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.
              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.

              Comment


              • #27
                Originally posted by RealNC View Post
                I believe that those two projects (and by extension, KDE and Gnome) are the most vital for the Linux desktop, and therefore should be considered the most important X.Org users. How else can Linux be on-par with Microsoft's Aero and Apple's Quartz? By not treating Compiz/KWin using the highest priority, improvements to the Linux desktop will continue to be glacial. I started reading Phoronix 3 years ago. Since that time, progress was slow, giving the impression that advancing the Linux multimedia desktop is not the highest priority of X.Org.
                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.

                Comment


                • #28
                  Originally posted by rvdboom View Post
                  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.
                  I think the complication here is that there truly are multiple "realities" in the Linux world, each representing a different possible path to increased market share, and each independent of the other (ie the requirements for one "path to success" are not requirements for another path, although having them all would be nice).

                  One of those realities is based on consumer user acceptance ie "Windows users", where the lack of universal support for the latest games and a few "unavoidable productivity apps" is widely regarded as all that is needed. Compositor support is nice but more than basic support is probably not necessary in this reality.

                  Another reality is arguably based on "attracting Mac users", where the top priority is regarded as having a top notch desktop environment and a few key applications, and where compositor support is clearly top priority.

                  There are a few other "paths to growth" including mobile platforms, but the key point here is that each one defines a subset of requirements which is sufficient for "success", and each is relatively independent of the other. What that means from a discussion POV is that each one *is* arguably a reality in its own right.

                  It makes for some interesting forum discussions
                  Test signature

                  Comment


                  • #29
                    Originally posted by kraftman View Post
                    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.
                    Or maybe there isn't universal agreement that expanding and enriching the desktop experience is the top priority in the first place...

                    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.
                    Test signature

                    Comment


                    • #30
                      Originally posted by marek View Post
                      not some desktop eye candy
                      I just want to point out that KWin is not about desktop eye candy. We use compositing to provide better usability (e.g. Present Windows, improved Task switching, ...) and better user experience (e.g. animations, blur). But it is not about eye candy. We have eye candy but none of the eye candy effects is enabled by default and if you read the blog post this Phoronix news is about, you would have realized that I want to have the eye candy effects out of KWin :-) In fact that's what we will do for Plasma Active in the short term.

                      This is one of the misunderstandings that I want to see resolved between KWin and Mesa/Xorg devs. We need to know what the other side means. E.g. if I say "We need to improve Compositing", I mean improving User Experience and if driver devs read this as "We need to ship more eye candy", we have a problem :-)

                      In the past with just Compiz it might have been that especially in the beginning there was a large emphasis on eye candy, but this has never been the case with KWin.

                      Comment

                      Working...
                      X