Announcement

Collapse
No announcement yet.

A Proposal To Fix The Full-Screen Linux Window Mess

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

  • #46
    Originally posted by Kasoroth View Post
    I would think that with all the video acceleration technology we have, upscaling or downscaling an image (with appropriate black bars for aspect ratio differences) wouldn't be too much of a performance problem. Video players have been handling full screen playback of arbitrary resolution sources on arbitrary resolution screens for a long time, and in my experience they tend to actually do a better job of scaling than most LCD monitors at non-native resolution.
    It is relatively trivial, the point is it's completely needless. Game designers usually want to maximize the frame rate as much as possible, and since you can avoid an upscale operation just by changing the resolutions (something other operating systems have been doing for awhile), there should at least be protocols set in place to correctly handle this if the application and WM want it. If there isn't, the eventually people will try and make a Wayland extension of some kind which they can call directly to bypass this limitation in Wayland's protocol. Then we'll end up with the same flaws we have today with applications directly setting the scene resolutions without setting it back if they crash (and not properly handling multi-monitor setups).

    I would actually prefer that programs not be able to change the real display resolution. ...
    That's cool, and ideally the WM would give you options concerning this. That's why I said it would only be a request the WM could choose to ignore (via upscaling the wl_surface), or handle it properly (by remembering previous resolution settings in case of a crash). Wayland is about simplifying and fixing the protocols, and this is obviously a sore spot for Linux gamers, so it's something Wayland should get right early on. A standard request protocol would allow for both ways to be done (you and I can both be happy) at the same time making the developers lives easier (they don't need to write upscale logic themselves, only request fullscreen).


    EDIT: Please disregard all that above.

    I just got conformation on the #wayland IRC channel, and Wayland does indeed work like I was hoping. Wayland provides a client request for mode/size/refresh-rate which the Compositor can choose to grant or ignore however it sees fit. Xrandr (and others) don't exist in wayland, so there's no danger of clients manually changing resolution. All applications have to do is create a wl_surface at a spefic size and request a resolution to match that. Looks like all my fears where for nothing. Awesome!
    Last edited by F i L; 10-25-2012, 06:43 PM.

    Comment


    • #47
      Originally posted by AJSB View Post
      You don't have a "office" screen with native 1280x1024 at 75Hz for sure to ask that


      Funny thing is that i solved the problem with my Window$ program
      No I have a TFT with 1920 x 1080 @ 60Hz native resolution. I also don't use Linux atm (missing it, but too lazy to install). What I still don't get is why it's not possible to just use XRandR + _NET_WM_FULLSCREEN. I think it makes more sense that the Xserver is responsible for changing the display resolution and the window manager is reponsible for dealing with windows. Maybe we should fix the issues with both instead of coming up with yet another hack.

      Comment


      • #48
        Originally posted by F i L View Post
        I just got conformation on the #wayland IRC channel, and Wayland does indeed work like I was hoping. Wayland provides a client request for mode/size/refresh-rate which the Compositor can choose to grant or ignore however it sees fit. Xrandr (and others) don't exist in wayland, so there's no danger of clients manually changing resolution. All applications have to do is create a wl_surface at a spefic size and request a resolution to match that. Looks like all my fears where for nothing. Awesome!
        Yeah, we have a sketch on the public fullscreen request on the desktop shell:
        http://cgit.freedesktop.org/wayland/...?id=1.0.0#n590

        That protocol doc does not say everything, the implementation still has lots of room to make decisions. For instance, one idea was, that when you alt+tab, the resolution does not change until you release the alt key, which makes choosing a window fluent. A resolution change could happen, when you move your focus from a normal app and raise a fullscreen app, or vice versa. Will it happen, depends on the hardware (is it supported nicely), compositor implementation (is it more performant than not changing resolution and doing something else), and user configuration (does user want the compositor to change resolutions ever? should it change resolutions of all fullscreen apps, not just those that really ask for it? etc.), and probably other things. Of course, if you don't change resolutions, the compositor has to do something else, that is still sensible. Ultimately all that should be configurable in compositor preferences. The protocol offers a way for an application to express the intent, and the compositor carries it out according to user preferences.

        This fullscreen request is specifically for temporary resolution changes for fullscreen apps, so that the compositor can accommodate the particular fullscreen-wannabe window the best way it can. Since the resolution is tied to the window, a disappearing window (a crashing game) will immediately return the whole output to normality.

        It is not the XRandr equivalent, which is for permanent (for this session) display configuration. For that we don't have an interface at all, yet.

        Comment


        • #49
          Originally posted by mememe View Post
          What I still don't get is why it's not possible to just use XRandR + _NET_WM_FULLSCREEN.
          Did you read this thread? What would be possible if the WM would handle it instead of the app (without nasty hacks):
          - Guaranteed multi-monitor compatibility.
          - Fake resolution (scale up/down).
          - Reset resolution back if the application crash.
          And maybe more. The WM could even decide to paint the fullscreen window as desktop background image (up/downscaled if needed).

          Comment


          • #50
            Originally posted by mememe View Post
            No I have a TFT with 1920 x 1080 @ 60Hz native resolution. I also don't use Linux atm (missing it, but too lazy to install). What I still don't get is why it's not possible to just use XRandR + _NET_WM_FULLSCREEN. I think it makes more sense that the Xserver is responsible for changing the display resolution and the window manager is reponsible for dealing with windows. Maybe we should fix the issues with both instead of coming up with yet another hack.
            Because having the WM know when/why a resolution change occurs means they can deal with it intelligently? Like, by saving current layout/widget state for restoration when the resolution goes back to normal.

            EDIT: The Wayland approach sounds excellent (eventually).

            Comment


            • #51
              Originally posted by TAXI View Post
              Did you read this thread? What would be possible if the WM would handle it instead of the app (without nasty hacks):
              - Guaranteed multi-monitor compatibility.
              - Fake resolution (scale up/down).
              - Reset resolution back if the application crash.
              And maybe more. The WM could even decide to paint the fullscreen window as desktop background image (up/downscaled if needed).
              If you can't set a non-native resolution (either because your display isn't very capable, or has an awful scaler), you can also use the overlays to do the scaling, which will provide you much better image quality at much lower power.

              Comment


              • #52
                Actually I was just playing Left 4 Dead 2 through Wine(steam made it free to play for 2 days) and my resolution got changed. I run KDE 4.9.2 under Ubuntu 12.10. While it wasn't correct when I exited(not the same as before the game, although it may have to do with an error that occurred during gameplay too), both with the incorrect one and after resetting it myself, all my widgets were pretty much how they should be( I just have a a few to monitor CPU, RAM and temperature on the desktop) . Is that certainly a problem with KDE as of now?(widgets getting messed up with resolution changes)

                Comment


                • #53
                  Originally posted by Kazade View Post
                  I actually started a very similar thread on the Wayland mailing list a couple of years ago: http://lists.freedesktop.org/archive...er/000080.html

                  The general concensus there was that games shouldn't be changing resolution, but instead, if the game requests a fullscreen resolution - the WM should provide the game a surface of the size it requested but then upscale that to fullscreen, perhaps even with sensible black-barring if the aspect ratio doesn't match the native resolution.
                  Why isn't this the standard? I mean, there is several advantages:
                  -Because its a window, it actually behaves properly on a multi monitor setup
                  -Don't dick the desktop if it crashes
                  -Possibly allowing the WM to select the used up/down scaling algorithm, which would be really nice for legacy applications
                  -Allowing a free setup of Super Sampling by setting the rendered resolution higher than the monitor
                  -Allows alt+tabbing smoothly without 2-3 second reblacking of the screen
                  -Allows WM to override the fullscreen, so it can be changed into a window too, seamless

                  Of course, it still don't change the fact that you need a sane scheme of locking the mouse inside the window, and various other goodies.

                  Comment


                  • #54
                    Originally posted by del_diablo View Post
                    Why isn't this the standard?
                    Because it requires a compositing window manager.

                    Comment


                    • #55
                      Originally posted by del_diablo View Post
                      Why isn't this the standard?
                      Because it's insane from a performance perspective.

                      Comment


                      • #56
                        I'm with the people that wants it like it was done in AmigaOS. Why should a games resoultion have any impact on the desktop at all? If a game was to open a 640x480 fullscreen then a alt-tab to the desktop should change back to 1920x1080 or what the desktop now was running, or is there something fundamentally wrong with X11 in this regard so that this isn't possible?

                        Comment


                        • #57
                          Gaming fits a different model

                          Contain the game in a Virtual Console. Avoid X, SDL and anything else except the kernel.

                          Comment


                          • #58
                            Originally posted by droste View Post
                            Because it requires a compositing window manager.
                            Hmmm, good answer.

                            Originally posted by pdffs View Post
                            Because it's insane from a performance perspective.
                            I rather doubt it. The performance of games in windowed modeus and fullscreen is identical on Windows, so if we wrote a sane scheme, why would it degrade?

                            Comment


                            • #59
                              Originally posted by del_diablo View Post
                              I rather doubt it. The performance of games in windowed modeus and fullscreen is identical on Windows, so if we wrote a sane scheme, why would it degrade?
                              Maybe unscaled... for scaling, Rasterman suggests somewhere between 5%-50% performance hit, since you need to add a minimum of about 3 buffer-swaps (up from 0) for the entire screen. And as I said earlier - the only time you legitimately want to change resolutions for gaming is when your hardware isn't powerful enough to run at native, so adding that performance hit couldn't come at a worse time.

                              Comment


                              • #60
                                But when do buffers swaps translate into real performance hit?

                                Comment

                                Working...
                                X