Announcement

Collapse
No announcement yet.

What Would Be A Win For KWin In KDE

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

  • #16
    Originally posted by curaga View Post
    How's that an issue? Compiz can just take a screenshot of the window before minimizing and show that. Problem solved.
    That's what KDE does. If you do the same on Windows though, you'll see that the thumbnail gets updated normally even when the window is minimized.

    Not that I actually care about this feature though. If I want to see the window, I simply restore it first. You can't see much in a thumbnail anyway. The only issue here is the "ha, see? Linux can't do that" effect.

    Comment


    • #17
      Originally posted by RealNC View Post
      The only issue here is the "ha, see? Linux can't do that" effect.
      Do you think that this is a good enough reason to kill X

      Comment


      • #18
        Originally posted by RealNC View Post
        I say this after having read the reply of X.Org devs to the main dev of KWin, telling him that neither Compiz nor KWin are the most important users of X.Org.
        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.

        Comment


        • #19
          Originally posted by RealNC View Post
          If you do the same on Windows though, you'll see that the thumbnail gets updated normally even when the window is minimized.
          Does it? I just checked on my Win7 (with Guild Wars and the Task Manager), and it doesn't.
          And it shouldn't, because I would hate to see a minimized window hogging major GPU resources just to keep a thumbnail updated.

          Comment


          • #20
            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.
            That's actually quite sad.

            Comment


            • #21
              Originally posted by RealNC View Post
              That's what KDE does. If you do the same on Windows though, you'll see that the thumbnail gets updated normally even when the window is minimized.
              That is not true. Windows do the same kind of thing as kwin, i.e. having this static thumbnail 'screenshot' of the window.
              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.

              Comment


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

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


                  • #24
                    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


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

                      Comment


                      • #26
                        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.

                        Comment


                        • #27
                          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


                          • #28
                            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


                            • #29
                              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

                              Comment


                              • #30
                                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.

                                Comment

                                Working...
                                X