On 01/09/2014 02:01 AM, Thomas Lübking wrote: > On Mittwoch, 8. Januar 2014 12:20:24 CEST, Roland Plüss wrote: > >> xwininfo: Window id: 0x5600001 (has no name) >> Depth: 24 >> Visual: 0x23 >> Visual Class: TrueColor >> Class: InputOutput >> Colormap: 0x20 (installed) >> Map State: IsViewable >> Override Redirect State: no > >> xwininfo: Window id: 0x5600005 "" >> Depth: 24 >> Visual: 0x27 >> Visual Class: TrueColor >> Border width: 0 >> Class: InputOutput >> Colormap: 0x5600004 (not installed) >> Map State: IsViewable >> Override Redirect State: no > > You might consider lookign into glXChooseFBConfig, but the outcome > looks unspectacular. > > Two things: > a) set the window override_redirect to take the WM (not the > compositor) out of the game. At least KWin had an issue about > reparenting an already managed window [1] (and I don't know whether > that happened to your client and iirc you mentioned reparenting a > hidden window works?) > b) Since iirc you mentioned KWin (? deleted OP) you might want to set > the compositor to XRender[2] to ensure it's not about GL and the > particular driver. > > Cheers, > Thomas > > [1] https://git.reviewboard.kde.org/r/109484/diff/ > [2] "kcmshell4 kwincompositing", 3rd tab I'll give this one a try.
Playing around a bit more with the problem I noticed the following behavior. Under FOX-ToolKit I get a similar problem but it is fixed there by forcing FOX to recalc the layout and position/move the window using FOX methods. Both are required to fix the problem. Under Firefox/NPAPI this trick can not be used so I played around with the window maximizing it and reverting it to normal. I set the window to be centered in the browser window for testing. Switch around I got an interesting effect. Let's say I start out with the maximized window. The GL window ends up in the wrong place. Now I revert the window to normal. The GL window is again in the wrong place for the normal window but the position it changed to matches the one it should have had in the maximized window. Same happens if I revert back to maximized. It looks thus as if the GL rendering output area lags behind the window position/size change as if the Compositor does apply the X event to the X window but swallows the update to the GL rendering and the next time a window X event is send this old change is applied to GL although the window is now again somewhere else. Could it be the compositor "forgets" to tell GL about the X window change? Since this does not happen with compositing disabled it somehow looks to me like if the compositor fails to properly send all events around. Assuming the compositor does forget to send the X event to GL after it processed it could I "repeat" the last X amount of events in the hope of getting the compositor to fix the problem? I'll see if the override redirect state helps the problem. I'll honk back tomorrow after I got a bag of sleep. (sleep deprived coders code crap :P ). -- Mit freundlichen Grüssen Plüss Roland Leader und Head Programmer - Game: Epsylon ( http://www.indiedb.com/games/epsylon ) - Game Engine: Drag[en]gine ( http://www.indiedb.com/engines/dragengine , http://dragengine.rptd.ch/wiki ) - Normal Map Generator: DENormGen ( http://epsylon.rptd.ch/denormgen.php ) - Sowie verschiedene Blender Export-Skripts und Game-Tools
signature.asc
Description: OpenPGP digital signature
_______________________________________________ [email protected]: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: [email protected]
