Re: Proposing _NET_WM_STATE_FULLSCREEN_EXCLUSIVE

On 10/26/2012 07:24 PM, Carsten Haitzler (The Rasterman) wrote:
> On Fri, 26 Oct 2012 12:23:34 -0700 Konstantin Svist <[email protected]> said:
>
>> On 10/26/2012 11:06 AM, Carsten Haitzler (The Rasterman) wrote:
>>> On Fri, 26 Oct 2012 10:45:53 -0700 Konstantin Svist <[email protected]>
>>> said:
>>>
>>>> * turning off other displays is usually NOT desired: if the game is not
>>>> using them, I would expect to be able to use a 2nd/3rd/etc. monitor to
>>>> display something else (reference information for the game, or maybe
>>>> email client/notification widget/etc.). If the user doesn't need to use
>>>> the extra monitors, she can turn them off manually.
>>> due to how randr does things keeping screens on is not desirable. it also
>>> means you can't turn off compositing. it's not sane/sensible to keep them
>>> on given the x11 setup we have at this time (changes would mean changes to
>>> xserver internals and implementations as opposed to just a wm<->app
>>> protocol).
>> I use XFCE desktop without compositing (not a fan of any sfx that slow
>> my wm down). Hope you're not saying I can only use 1 monitor in this case?
>> Agree on not having to support full 3D-accellerated desktop while a game
>> is running, but here's a thought: since it doesn't need to be
>> interactive, why not render it in 2D for the duration? If some dynamic
>> widget updates, it can be re-drawn [with low priority], and then left as
>> static image on screen.
> this doesn't have to do with 3d accel at all. it's entirely buffer FLIPPING vs
> buffer COPYING. and it's for the 3d game window. currently drivers have an
> optimization. it goes something like this:
>
> if 3d window is "on top" AND has no shape AND it is the EXACT dimensions of the
> framebuffer, then do buffer FLIPS, otherwise COPY from backbuffer to
> framebuffer.
>
> so literally every time the game does a swapbuffers the backbuffer is EXCHANGED
> with the current framebuffer. this leads to ZERO copying of pixels to do the
> swap. all games that use gl do this (realistically). so by just keeping your
> 2nd screen around at all in any way or form, you'll impact performance. this
> can impact performance anywhere from maybe 5% to 50%. depending on the game
> and nature of rendering, gpu, framebuffer size etc. - this is all because both
> the screens become a big single framebuffer in hardware.

I'm pretty sure gamers who use multiple screens know what to expect. I 
wouldn't run an FPS with an extra desktop turned on, that's true -- but 
a low-graphic-requirement game is a whole different story.
It's not problem without a solution -- maybe use a separate framebuffer, 
or give user a choice/warning ("shrink desktop or suffer low performance")


> there is also another reason. let's say that your left monitor is where you
> want the game, and the right is where you keep your "windows". your left
> monitor is currently at 1600x900. your right is at 1600x900. when the game
> wantsa to change resolution, it asks for 1920x1080. this means there is no
> SPACE on the left area to shrink, so you have to reconfigure both screens, move
> all the windows and content around on the 2nd screen and shuffle them over to
> the right by 320 pixels to make room for the expanded left monitor region. this
> will lead to "artifacts" when starting/stopping the fullscreen mode.

How is this different from resizing the left monitor with xrandr? That's 
doable right now