Exclusive Fullscreen Mode

[Roland Plüss]

On 09/07/2010 06:08 PM, Thomas Lübking wrote:
> Am Tuesday 07 September 2010 schrieb Roland Plüss:
>> What exactly you mean with this? What I'm looking for is if the
>> compositing is disabled if a window goes fullscreen.
> and to quote myself: "by default yes" 
>
> KWin is the KDE WM and by default un-redirects fullscreen windows (and the 
> only way for a user to change that is to edit the config file by hand)
> This does of course NOT happen for a translucent (NET_WM_OPACITY) "fullscreen" 
> window.
> (There is no "fullscreen mode" in X11, there's a screensize window and a NETWM 
> hint for the WM, which you should btw. use by all means since otherwise many 
> WMs will not handle a window as "fullscreen" just because it's screensized)
>
> If you really mean "disabled" like deleting th GL context, afaik at least 
> compiz can't "disable" compositing at all, not sure about E17 module 
> capabilities and kwin does NOT suspend compositing in this case (you'd have to 
> call this via dbus) but just skips the expensive tfp conversion for the 
> fullscreen window.
Ah okay. I didn't get at first if this had been supposed to be an answer
to my question. This all does make sense. If compositing doesn't operate
on the GPU while a fullscreen window is shown this should be indeed
enough to keep the resources free for the game.
>> With exclusive fullscreen one can fully grab all GPU RAM and work with it.
> Maybe in your wet dreams ... let's say:
> "since the compositor does not bind textures i'll get more of mine to VRAM"
>
> This is however pretty irrelevant as the driver maps/copies textures to system 
> RAM (and in doubt from there to disk) and since the compositors textures are 
> ideally not accessed during the rendering of a FS & unredirected window, a 
> smart driver would preferably keep the textures of the FS GL client in VRAM.
>
> If you try to allocate VRAM on a driver level you'll likely invalidate the 
> various buffers as well as X11s resource cache.
> (And if you do not work for nvidia, you won't be able to do this on at least 
> their css drivers ;-P )
>
> Notice that various drivers also at least /used to/ statically split the VRAM 
> between GL & X11 - i frankly don't know whether this is still the present 
> sota.
It's more about how much GPU RAM one uses in a game before hell breaks
loose. Obviously it's a bit more tricky to manage the available GPU RAM
if you don't know how much RAM other apps (composite in this case)
snagged already. But if the apps don't mess with OpenGL anymore while
the fullscreen game runs the amount of free GPU RAM before the game
starts until it stops should be somewhat equal. That's enough for the
time being.
>> Xlib is a requirement. Toolkits are therefore a no-go.
> Sorry, but that deduction "X11 -> !Toolkit" makes _no_ sense at all. Nothing 
> prevents you from using Xlib directly while in general utilising some toolkit 
> for an easy life, portability and a somehow documented API (yes, X11 API doc 
> is lousy, now ban me ;-)
Indeed it does. Using a toolkit "forces" all code in a project to use
that toolkit. For the editor application and some debugging modules this
is okay but for the bare graphic part of the engine any kind of toolkit
is a strict no-go. Or have you ever tried to import a widget created
with FOX into let's say Qt or vice-versa at run-time? It's hate if it's
even possible (meaning juggling X-IDs around... *shudder*). It's already
tricky enough to import a pure Xlib window into FOX in a crossplatform
way. So no, for the pure engine level anything above Xlib/Win32/BMedia
is a no-go and causes troubles. The editors and the launcher though are
using FOX. They do though also only the GUI part and the rendering is
done by the engine using pure Xlib.
>> Concerning OpenGL I never heard of the ability to change screen resolution. 
> Is this some extension or GLX only code?
> The easiest way is glutEnterGameMode() and friends, but since you refuse 
> toolkits... (no idea whether it calls through to some lower level GL or 
> directly X11 function, sorry)
Ah, that's GLUT. That's also a strict no-go in this project. And I'm
pretty sure it calls through to X11 since OpenGL does not contain any
calls to tamper with the presenting screen as this is a graphics library
not a window manager. Creating and handling a presentation window is the
problem of the application using whatever GUI system the platform in
question has. OpenGL kicks in once such a presentation window exists and
simply creates a context in which rendering takes place. I would be
astonished if it would go beyond.

-- 
Mit freundlichen Grüssen
Plüss Roland

Leader und Head Programmer
- Game: Epsylon ( http://www.indiedb.com/games/epsylon ,
http://epsylon.rptd.ch )
- Game Engine: Drag[en]gine ( http://www.indiedb.com/engines/dragengine
, http://dragengine.rptd.ch )
- Normal Map Generator: DENormGen ( http://epsylon.rptd.ch/denormgen.php
) and others

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20100907/8b1df71e/attachment.pgp>