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 677657 - Skype screen share freeze gnome-shell
Skype screen share freeze gnome-shell
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
3.2.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2012-06-07 22:38 UTC by Daniele Segato
Modified: 2012-06-08 21:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
meta-window-actor: Refactor should_unredirect a bit more (2.80 KB, patch)
2012-06-08 03:33 UTC, Jasper St. Pierre (not reading bugmail)
committed Details | Review
meta-window-actor: Don't unredirect shaped windows (1.19 KB, patch)
2012-06-08 03:33 UTC, Jasper St. Pierre (not reading bugmail)
committed Details | Review

Description Daniele Segato 2012-06-07 22:38:48 UTC
I'm experiencing an issue with gnome-shell and the skype "screen share" feature.


It's the same documented here:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/879895

and here:
https://jira.skype.com/browse/SCL-809

I had a chat in IRC, GimpNet, #gnome-shell, I described the issue generating a chat among three channel members that at the end agreed this was a bug in gnome-shell.

And I can confirm this is not happening with other Window Managers (like unity, metacity etc..)

when a screen share start skype usually draw a red border at the edge of the screen: on gnome-shell when I initialize a screen share I can't interact with the desktop anymore: only the right click of the mouse work.

Usually the Top Bar is gone.


if the other user send me chat message I can interact with the desktop for a while (my guess is that gnome-shell is giving the "focus" to something else to show the notification during that period)


On IRC they explained to me this is happening because gnome shell has an heuristic to unredirect (from the composite overlay window) drawing for games, to increase their performance.

Apparently skype erroneously fall into that euristic and is unredirected, even if it's transparent: thus "covering" the cow, which them seems completely still.

I'm no gnome expert but I think I can understand what's going on here, and I think it's a gnome-shell bug, colliding with skype behavior but to be fixed within gnome-shell.

Furthermore I've read of similar issues with other softwares like recordmydesktop which exibit similar behavior.

I can attach a photo of the screen I took while the system was unresponsive if you wish, but I don't think is really useful.

Thanks
Comment 1 Jasper St. Pierre (not reading bugmail) 2012-06-08 03:33:13 UTC
Created attachment 215889 [details] [review]
meta-window-actor: Refactor should_unredirect a bit more

"Flat is better than nested"
Comment 2 Jasper St. Pierre (not reading bugmail) 2012-06-08 03:33:17 UTC
Created attachment 215890 [details] [review]
meta-window-actor: Don't unredirect shaped windows

If a window has its BoundingRegion shaped, we shouldn't unredirect it,
as it expects the rest of the windows from being shown under it. This
prevents applications like the Skype screen recorder or gtkRecordMyDesktop
which want to show a "border" around the recorded area from being
unredirected, giving the appearance of making the desktop freeze.
Comment 3 drago01 2012-06-08 07:36:32 UTC
Review of attachment 215889 [details] [review]:

Looks good.
Comment 4 drago01 2012-06-08 07:42:16 UTC
Review of attachment 215890 [details] [review]:

As discussed on IRC this one is right ... but I can't test this right now.
Assuming it works find to commit.

BTW. we probably should do the same for the chrome in gnome-shell? (Keep showing the chrome if the topmost window is shaped?).
Comment 5 drago01 2012-06-08 07:42:52 UTC
(In reply to comment #4)
> Review of attachment 215890 [details] [review]:
> 
> As discussed on IRC this one is right ... but I can't test this right now.
> Assuming it works find to commit.
> 
> BTW. we probably should do the same for the chrome in gnome-shell? (Keep
> showing the chrome if the topmost window is shaped?).

s/find/fine/ ;)
Comment 6 Jasper St. Pierre (not reading bugmail) 2012-06-08 07:48:12 UTC
Review of attachment 215890 [details] [review]:

That opens a whole can of worms. The same can of worms that happened when we talked about hiding the chrome on non-100%-opacity-windows. I'd rather not.
Comment 7 drago01 2012-06-08 08:02:04 UTC
(In reply to comment #6)
> Review of attachment 215890 [details] [review]:
> 
> That opens a whole can of worms. The same can of worms that happened when we
> talked about hiding the chrome on non-100%-opacity-windows. I'd rather not.

Good point.
Comment 8 Jasper St. Pierre (not reading bugmail) 2012-06-08 16:59:08 UTC
So ACN?
Comment 9 drago01 2012-06-08 17:00:24 UTC
(In reply to comment #8)
> So ACN?

"As discussed on IRC this one is right ... but I can't test this right now.
Assuming it works fine to commit."

Still applies ... the chrome comment is unrelated to the patch itself.
Comment 10 Jasper St. Pierre (not reading bugmail) 2012-06-08 20:49:21 UTC
Attachment 215889 [details] pushed as 4041f96 - meta-window-actor: Refactor should_unredirect a bit more
Attachment 215890 [details] pushed as 66eac78 - meta-window-actor: Don't unredirect shaped windows


Took a little while, but I finally got it tested with this little test
case I wrote:

http://fpaste.org/126A/
Comment 11 Daniele Segato 2012-06-08 21:04:35 UTC
Good, can this be backported to Gnome 3.2.x or will we have to wait for Gnome 3.4?

Thanks
Comment 12 Jasper St. Pierre (not reading bugmail) 2012-06-08 21:09:27 UTC
GNOME 3.4 is already out. And there are no more planned releases of GNOME 3.2 or GNOME 3.4.
Comment 13 drago01 2012-06-08 21:22:26 UTC
(In reply to comment #12)
> GNOME 3.4 is already out. And there are no more planned releases of GNOME 3.2
> or GNOME 3.4.

We can do releases whenever we feel the need for doing it. Back porting this to 3.4 sounds reasonable.