Re: Proposing _NET_WM_STATE_FULLSCREEN_EXCLUSIVE

[Carsten Haitzler (The Rasterman) <raster rasterman com>]

On Sat, 27 Oct 2012 00:19:47 -0400 "Ryan C. Gordon" <icculus icculus org> said:

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

for managed windows there is no need for an app to ever listen for randr events
- the wm will "deal with it" when the screens reconfigure. (right now for
example e17 just takes the "lost screen" and all its virtual desktops and dumps
then onto one of the screens that is still left around).

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

sure - in the end even if the spec is aggressive/restrictive, wm/shell authors
are going to just poopoo any spec elements they think are unreasonable anyway.
ie they will just re-interpret as they see fit. the point is though to ensure
the intent is explained do the wm does the logical/right thing by both the app
and the user. if it doesn't then users are in their rights to complain to the
wm authors and report bugs. i think what is important here is to ensure there
is a clear line of responsibility, so users dont report bugs to game devs for
issues that are wm ones, or if they do that it's easily redirected.

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

you don't have games that can span multiple screens for wide field of view? :)

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

the wm may choose to still display panels and stuff... it's up to the wm really.

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

hehe sure. 320x240 etc. are pretty much gone. do you expect the game to go to
randr and query available modes? does this sound sensible actually? i don't
think it does as game doesnt know what monitor it is destined for until its
window is mapped. i suspect we need to have some level of negotiation here.
maybe wm advertises available exclusive fullscreen resolutions in a property,
and then game selects one of them.

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


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster rasterman com