Owen, this is really great feedback, thank you. > Why not let the Compositor decide how to best present the window? If > the compositor can change the resolution, then it can resolution. If the > compositor would rather scale the window up, then it can scale up. > In the xwayland world, the compositor would probably just set the video > display to scan out directly from the window pixmap.
After reading all the discussion on this list, and Slashdot/Reddit/Phoronix/etc, I think this is a reasonable idea. As far as the game is concerned, it wants to own an entire screen and keep its current window dimensions, so I could see the render-to-a-smaller-backbuffer-and-scale-up approach working as an option, transparent to the application. There's been a lot of passionate arguments for both resolution switching and scaling via the compositor, and technical pros and cons to each. I can envision some desktop environments favoring one or the other, or the really hardcore having a checkbox in a system preference to let the user decide which behavior works best for their needs. I think this was one of the bigger points of contention, and making the language accommodate either approach should make everyone happy. > "The Window Manager MUST protect desktop state (icon positions, > geometry of other windows, etc) during resolution change, so > that the state will be unchanged when the window ceases to be marked > as fullscreen." > > This is just a SHOULD or quality-of-implementation issue - the > application itself doesn't care that this happens. (When changing the > resolution, it may be impossible, since applications can listen directly > for resolution changes.) I think this is sort of important. Certainly the Window Manager can't stop something that is listening for XRandR events from responding, and it probably shouldn't for the rare cases where might be useful. Perhaps we shouldn't say "MUST protect desktop state" and instead "MUST NOT change desktop state" ... if an application changes itself at this point, I don't think the WM should fight it. Does that sound reasonable? I assume the set of apps listening for XRandR events directly is extremely small: popup windows that don't want to remain on a disconnected monitor, a display configuration panel, etc. Most just get moved around by the Window Manager when the WM itself sees an XRandR event, right? > In general, I think what is important here is that the application is > describing an intent about the treatment and the window manager is free > to do whatever it can to best implement that. We were admittedly overaggressive about dictating behavior. We were afraid that there would be a variety of (incorrect) interpretations and not be any better off at the end of the day. That being said, these discussions are going to result in dialing some of that aggressiveness back, so I think the end result will be better: specific, but not stiflingly restrictive. > * How do you see this working with respect to multihead? > Can it be used in conjunction with _NET_WM_FULLSCREEN_MONITORS? I'm inclined to say no. It seems like a lot of complexity for small gains. I'm not against the idea, though, if anyone wants to argue for it. > * Would it make more sense to simply resize the window to the > size of the closest resolution rather than requiring the window > manager to obscure other portions - that would have a couple > of advantages: No, if resizing the window was acceptable, we'd just use the existing _NET_WM_STATE_FULLSCREEN atom. I'm personally uncomfortable with asking the window manager to obscure the empty space, but I don't see a better option. Certainly even the compositor that doesn't change resolution will have to deal with aspect ratio differences, for windows that want a 4:3 aspect on a screen that is 16:9, so there's always going to have to be _something_ that deal with obscuring an unused part of the screen. In a perfect world, games only request existing resolutions so it's always a perfect fit, but in practice that doesn't always happen. The only way I'm willing to bend on this is if we have the WM refuse to change the resolution if it can't get a perfect fit, but I think we'll all lose a little bit in that case, especially as monitors stop offering smaller resolutions and that DOSbox game that ran at 320x240 no longer runs on your brand new machine. (DOSbox might be a bad example, as it probably has scaling, but you get my point.) > * The requirement to iconify when the window loses input focus > conflicts with desktop environments where iconification is not > part of the user interface. I think any specification should > instead require switching the window back into windowed mode, > or to allow both. I can get on board with this. The goal is to make it so apps can't hijack the display unconditionally (within reasonable parameters), and either approach solves the problem. > * I don't like the reference to "current dimensions" - current > dimensions is something that the app doesn't control. It would > be better to specific the sizing with respect to the geometry > hints to on the window - for example, the minimum size of the > window. Yes, this is absolutely right. I'll correct the spec. > * I'm not sure that I fully understand how everything that you've > bundled in here fits as a unit. The "EXCLUSIVE" part of this > proposal - the specification of what happens when the window > loses focus - seems actually like a behavior that would apply > as much to a presentation program as to a game. Do we have > in mind a class of applications that wants different behavior? (another email in this thread suggested that "_EXCLUSIVE" was probably the wrong word, so we'll probably change that.) The example given in the existing _NET_WM_STATE_FULLSCREEN documentation is a presentation program, and I think that class of application should keep using the existing hint. For those apps, I'm thinking about OpenOffice/Keynote/PowerPoint saying "don't try to screw with the projector's resolution because I'm happy it's working at all; just make my window as big as the resolution currently is." Another example is telling your web browser "give me every pixel you can on this monitor for "full screen mode." The salient differences: these two examples can render to any reasonable resolution, don't have a pressing need to render at a non-native resolution, don't care about refreshing at 60 frames per second, and aren't as concerned with "immersion," which is a subjective term, but no less important. > Perhaps this just needs to be some sort of advice-to-implementors > about what happens when a full-screen window loses focus? > (With details about what should happen for windows that are > transient-for that window like dialogs.) And then the rest > of this is simply a flag about how the application wants to be > fullscreened, rather than a separate type of fullscreening? Another related question someone asked is whether input focus is the appropriate metric at all; if I've got my email client on a second LCD while playing a game on the first, when I alt-tab over to reply to some mail, I shouldn't hide the game for no reason. Maybe we should change "when the window loses input focus" to "when another window is placed above the fullscreen window in the z-order"? I'm not sure what the right language (or approach) should be here, and would welcome opinions. We certainly don't want the little volume control widget that pops up when you hit the volume buttons on the keyboard to rip you out of your game, so the wording is tricky here. --ryan. _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org https://mail.gnome.org/mailman/listinfo/wm-spec-list
