GNOME Bugzilla – Bug 627880
Steam windows appear tiled in many copies on screen with compositing enabled
Last modified: 2012-04-25 21:52:36 UTC
Created attachment 168677 [details] Multiple copies Note: I originally reported this in the Wine bug tracker. I was told it's likely that the cause is a bug in the window manager, and there's some evidence to support that. Please see the discussion in http://bugs.winehq.org/show_bug.cgi?id=23841 The "new" Steam UI running under Wine has a weird effect when run along with a compositing window manager. Instead of one copy of the window, multiple copies appear tiled to the right and down. Only the top-left copy is "solid" in the sense that it's the only one that receives events. Clicking on a copy sends the events to the window below (another application or the desktop). All copies reproduce the changes in the main copy. I've reproduced this with Gnome-Shell, plain Mutter, and Metacity in compositing mode. Metacity with compositing mode disabled doesn't exhibit this problem. I'm attaching a screeshot made with Gnome Shell. Metacity shows a different effect: instead of the extra copies, it shows filled black. Curiously in the "expose" mode of Gnome Shell (i.e. when the desktop is zoomed out) the window appears correctly. I haven't tried similar features of the other window managers.
Have you tried with Compiz? Metacity in compositing mode shares almost no code with Mutter, so it's almost certain that you are revealing a video driver bug of some sort. (You don't say anything about your video driver or graphics hardware.)
I'm using nVidia's proprietary drivers 195.36.24-4 with a 9800 GTX+ card. I haven't tried with Compiz, but I can try to do that tomorrow. Just to make sure what you have in mind, are you suggesting that if it also happens with Compiz, then it's unlikely to be caused by the window manager?
If it also happens with Compiz it is not caused by the window manager.
I've just confirmed that it doesn't happen with Compiz 0.8.4-4.
OK, good to know. It's still almost certainly a driver bug or possibly a Wine bug, though.
I can reproduce this behavior. Different hardware/driver version though still NVIDIA. If someone has nouveau supported hardware and tested we could see if it's something in the driver. Interesting that it doesn't happen in the overview.
Created attachment 187834 [details] [review] Clip the shaped region to the bounding region According to the XShape specification, the shaped region should always be a subset of the bounding region. Certain programs such as wine depended on this behavior.
Unfortunately, XShape broke recently... so this patch requires bug #635268 to be fixed.
*** Bug 653400 has been marked as a duplicate of this bug. ***
Review of attachment 187834 [details] [review]: This doesn't handle the case of the bounding rectangle changing without the shape changing - so we might leave the shape clipped to the last bounding rectangle. Now, it really should work fine right now since we set the "needs_pixmap" flag in meta_window_actor_sync_actor_position() which gets called synchronously, and we set the needs_shape flag when we get events back from the X server, and we (right now) always set a new shape when we set a new size, but with the changes planned for the "invisible borders" patch, we'll then be tracking a shape that's set by the application whenever it wants, and is unconnected to setting a new size. So, I think meta_window_actor_update_bounding_region() needs a: if (priv->shaped) meta_window_actor_update_shape(); with an appropriate comment. ::: src/compositor/meta-window-actor.c @@ +1713,3 @@ + + if (priv->bounding_region != NULL) + cairo_region_intersect (priv->shape_region, priv->bounding_region); I'd like to see a comment here along the lines of /* shape_region here is the "bounding region" as defined in the * X SHAPE extension, while bounding_region is the "bounding * rectangle" in the shape extension. All shape regions set * via SHAPE are implicitly clipped to the bounding rectangle * when used inside the X server, but not when retrieved, so * we need to do that that clip explicitly here */
Created attachment 191050 [details] [review] Clip the shaped region to the bounding region According to the XShape specification, the shaped region should always be a subset of the bounding region. Certain programs such as wine depended on this behavior.
Review of attachment 191050 [details] [review]: Minor nits, otherwise looks good to commit ::: src/compositor/meta-window-actor.c @@ +1699,3 @@ + */ + + meta_window_actor_invalidate_shadow (self); Extra blank line above this @@ +1723,3 @@ + + /* Our "shape_region" is called the "bounding region" in the X Shape + * Extension Documentation[0]. Broken link... (Not sure a bibliographic entry is needed - someone can find it if they need it :-) @@ +1730,3 @@ + * The X Shape extension requires that the "bounding region" can never + * extend outside the "bounding rectangle", and says it must be implicitly + * clipped before rendering, so the region we get back hasn't been clipped. Not sure there's a ", so" here - would be fine as "rendering. The region..."
Created attachment 191053 [details] [review] Clip the shaped region to the bounding region According to the XShape specification, the shaped region should always be a subset of the bounding region. Certain programs such as wine depended on this behavior. grr... fix a compile issue that I forgot to squash
Created attachment 191055 [details] [review] Clip the shaped region to the bounding region According to the XShape specification, the shaped region should always be a subset of the bounding region. Certain programs such as wine depended on this behavior. This good?
Attachment 191055 [details] pushed as 2b93c19 - Clip the shaped region to the bounding region
Oops. Did not mean to change this to fixed. John or Javien -- can you look at Steam and verify that the situation is better, and note any additional bugs you have?
On which file should the patch be applied and where is it located? I've got Gnome 3 from the F15 installation, I didn't compile it from source.
You need to build from source if you want to apply this patch.
Alright. What's the procedure to set the compiled-from-source Gnome shell as the default, and will it cause some dependencies to break on F15?
(In reply to comment #19) > Alright. What's the procedure to set the compiled-from-source Gnome shell as > the default, and will it cause some dependencies to break on F15? The most sane option is to build with jhbuild, or upgrade to F16 beta. To do the former, see http://live.gnome.org/GnomeShell#Building To do the latter, see http://fedoraproject.org/wiki/Upgrading
Cool! Thanks so much for your help!
Confirmed fixed.