From freedesktop-xorg Tue Sep 07 16:08:14 2010 From: Thomas =?iso-8859-15?q?L=FCbking?= Date: Tue, 07 Sep 2010 16:08:14 +0000 To: freedesktop-xorg Subject: Re: Exclusive Fullscreen Mode Message-Id: <201009071808.14920.thomas.luebking () web ! de> X-MARC-Message: https://marc.info/?l=freedesktop-xorg&m=128387764027449 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. > 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. > 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 ;-) > 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) Cheers _______________________________________________ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: freedesktop-xorg@progressive-comp.com