After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 518712 - Underlying windows interacts badly with GL-apps
Underlying windows interacts badly with GL-apps
Status: RESOLVED DUPLICATE of bug 562669
Product: metacity
Classification: Other
Component: Iain's compositor
trunk
Other Linux
: Normal normal
: ---
Assigned To: Metacity compositor maintainers
Metacity compositor maintainers
: 543362 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-02-25 21:45 UTC by Sven Arvidsson
Modified: 2009-07-15 20:39 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20


Attachments
GL window on top (59.57 KB, image/jpeg)
2008-09-14 09:24 UTC, Jack Malmostoso
Details

Description Sven Arvidsson 2008-02-25 21:45:41 UTC
There's some bad interaction between GL-apps and underlying windows which is being updated.

For example, when running glxgears fullscreen, I get big black rectangles anytime an underlying window (for example the panel clock, or top running in a terminal) is being updated and redrawn.

This problem does not exist when using xfm4 with compositor, and I have a dim memory of it not existing when the metacity compositor was on a separate branch (but I could be wrong of course).
Comment 1 Thomas Thurman 2008-03-17 02:04:33 UTC
Might this be related to bug 522166, do you think?
Comment 2 Sven Arvidsson 2008-03-17 18:52:30 UTC
I don't think so. The behaviour is the same in both revision 3452 and 3453.

I will keep trying older revisions and see when it broke.
Comment 3 Sven Arvidsson 2008-03-21 22:01:26 UTC
I have tried quite a few different revisions from the branch now, and all with the same result. 

I could be wrong, and this never worked. Still, it would be great if someone could figure out what xfwm4 does different and fix it for metacity.
Comment 4 iain 2008-05-24 20:42:59 UTC
(In reply to comment #1)
> Might this be related to bug 522166, do you think?

Its nothing to do with that...
We need to turn off compositing when a window is fullscreen. Thats what xfwm does
Comment 5 iain 2008-09-07 00:29:56 UTC
*** Bug 543362 has been marked as a duplicate of this bug. ***
Comment 6 Jack Malmostoso 2008-09-14 09:24:33 UTC
Created attachment 118691 [details]
GL window on top

I would like to confirm this behaviour, and add that the GL content always sits on top of every other window, even if the window itself is in the background. See the attachment to understand what I mean.

Disabling the compositing manager makes both problem (redraw and sitting on top) go away.

If there's anything to test, please share.

Thanks!
Comment 7 Sven Arvidsson 2009-01-26 20:55:14 UTC
DRI2 nicely solves all the problems the compositor runs in to with opengl and fullscreen video.

Since it will still be some time before the majority of the Xorg drivers can take advantage of this (and some drivers might never be ported..) it would still be nice to have this available as a workaround if it doesn't mean a ton of work.
Comment 8 Sven Arvidsson 2009-04-17 15:03:41 UTC
The tearing free video fixes in the intel driver (and possibly other drivers too?) only works in an non-composited environment, so that's another argument for having this feature.

(There is ongoing work to get tearing free video with a compositor, but that's only for GL-based compositors which means waiting for Mutter.)
Comment 9 Sven Arvidsson 2009-07-15 20:39:23 UTC
Bug 562669 was retitled to track the request for unredirected fullscreen windows, so let's just mark this one as a duplicate.


*** This bug has been marked as a duplicate of 562669 ***