Re: Proposing _NET_WM_STATE_FULLSCREEN_EXCLUSIVE

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

On Thu, 25 Oct 2012 19:40:49 +0200 Martin Gräßlin <mgraesslin kde org> said:

> On Thursday 25 October 2012 13:29:13 Ryan C. Gordon wrote:
> > > Also in the case of KDE Plasma Workspaces the window manager is not at all
> > > responsible for handling the resolution. This is done by a daemon called
> > > krandr. I will not add code to change the resolution as that is nicely
> > > handled by krandr. So we would need to announce the support only if the
> > > daemon is present - this is something we would most likely not be able to
> > > guarantee correctly as in session start KWin should be started before
> > > krandr and it's possible that KWin is run outside a KDE Plasma session.
> > 
> > To be clear, I don't think _any_ window manager currently has code to
> > change resolutions (indeed, the core of the problem is that the app is
> > doing that itself without any coordination with the system). I think
> > it's great that KDE has a clear chain of responsibility for who is
> > allowed to interact with XRandR, which means this can be cleaner for you
> > than it might be for, say, Gnome.
> > 
> > How I would envision this working is something like this (I have no
> > experience with KDE source code, so this might be pure fantasy on my
> > part)...
> > 
> > - krandr sends a notification to KWin once it starts up, and then KWin
> > can begin advertising the appropriate atoms. If a fullscreen app wants
> > to start up in the very first seconds of the KDE session: too bad, but
> > if we're being really fancy, KWin could stall that app until krandr is
> > ready.
> > - If you run KWin outside of a Plasma session--and therefore never have
> > krandr--KWin never advertises the atoms and never supports the
> > extension. That's what you get for not running KDE the way God intended.  :)
> > - An app requests the _NET_WM_STATE_FULLSCREEN_EXCLUSIVE atom, KWin asks
> > krandr to change resolutions, and does NOT resize any of the windows or
> > move around desktop icons (etc) when it gets the resolution change event.
> > It makes the appropriate window the top of the Z-order, etc. Other apps
> > have no idea anything has changed for the most part.
> > - When the window loses focus (user alt-tabbed out of the game, window
> > is legitimately being destroyed, etc), repeat this process, telling
> > krandr to return to the original resolution.
> > 
> > I'm ignoring some of the minutiae here, but that's the basic gist of it.
> > Does this sound like a reasonable approach for KWin?
> Honestly? No. That would be way too invasive change to the handling of KWin 
> internals. E.g. we currently do not support changing the atom what KWin 
> supports also to not handle the resolution change is not at all trivial.

errr... ummm... changing that property is a triviality... i fail to see how you
can "not support changing it" withotu actually going ot lots of effort to make
it not possible.

> If someone would propose a patch to do that I would probably not accept it
> due to the many possibilities that this could go wrong. I don't like fragile
> code.
> 
> I think on this thread a good approach has been highlighted: upscaling in the 
> compositor and not changing the resolution. That would not be invasive in 
> KWin.

this is a horrible approach. reasons:

1. you don't have input redirection in x (xeviv is dead) so this can't be made
to work anyway.
2. this spits in the face of the idea of using a lower resolution. if this was
a good idea games would do it themselves - ie render to FBO THEN render FBO as
upscaled texture to backbuffer, then swap. this is basically now what you do
in the compositor *IF* you upscale in compositor, but done game-side.
3. spits in face of performance.

that becomes and extra buffer copy... of the entire screen buffer. that
matters. depending on the game, gpu and resolution that can easily knock
anything from 5% to 50% off your framerate. easily. considering my day job
involves embedded gpu work, we've spent a lot of effort in efl to cut out this
kind of nonsense in the rendering pipeline because this literally can double
your framerate, and when you are struggling to do 60fps on some full-hd screen
on an arm soc.. this stuff matters like no mans business. and it mattters on
desktops too. and laptops. you go from ZERO copies for a swap for a fullscreen
window (buffers are actually exchanged by the driver. i know this actually
happens on both intel and nvidia drivers these days), and you ADD a copy
+upscale. this lowers performance, lowers battery life etc. etc.

this is far from a great solution. it's the "solution of last resort if you
have absolutely nothing else".

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