opengl windows bugged placement on compositing

[Roland Plüss]

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

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