On Fri, 26 Oct 2012 21:59:28 -0700 Konstantin Svist <fry....@gmail.com> said:
> On 10/26/2012 07:24 PM, Carsten Haitzler (The Rasterman) wrote:
> > On Fri, 26 Oct 2012 12:23:34 -0700 Konstantin Svist <fry....@gmail.com>
> > said:
> >
> >> On 10/26/2012 11:06 AM, Carsten Haitzler (The Rasterman) wrote:
> >>> On Fri, 26 Oct 2012 10:45:53 -0700 Konstantin Svist <fry....@gmail.com>
> >>> 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
you can size it down use a viewport to only see part of the original left
screen, thus not affecting anything on the still visible right-screen.
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
_______________________________________________
wm-spec-list mailing list
wm-spec-list@gnome.org
https://mail.gnome.org/mailman/listinfo/wm-spec-list
