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 734054 - ui: always set the frame background to None
ui: always set the frame background to None
Status: RESOLVED FIXED
Product: mutter
Classification: Core
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
Depends on:
Blocks:
 
 
Reported: 2014-07-31 15:43 UTC by Giovanni Campagna
Modified: 2014-08-04 09:30 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
ui: always set the frame background to None (10.29 KB, patch)
2014-07-31 15:43 UTC, Giovanni Campagna 		committed Details | Review

Description Giovanni Campagna 2014-07-31 15:43:30 UTC 
This way the xserver never paints the frame background, even if
the client window is destroyed. This allows us to have clean
destroy window animation.

There is no problem with interactive resizing because applications
are using the XSync protocol, so we're not painting unless the
client has redrawn.
Comment 1 Giovanni Campagna 2014-07-31 15:43:32 UTC 
Created attachment 282171 [details] [review]
ui: always set the frame background to None
Comment 2 Jasper St. Pierre (not reading bugmail) 2014-07-31 15:51:40 UTC 
Review of attachment 282171 [details] [review]:

OK.
Comment 3 Giovanni Campagna 2014-07-31 15:54:27 UTC 
Attachment 282171 [details] pushed as d0f2c6b - ui: always set the frame background to None
Comment 4 drago01 2014-08-03 08:11:58 UTC 
(In reply to comment #0)

> There is no problem with interactive resizing because applications
> are using the XSync protocol, so we're not painting unless the
> client has redrawn.

"because applications are using the Sync protocol" ... that is only true for gtk3 apps. Not gtk2, qt, java swing, ...

You should probably just do it for apps that do use the sync protocol.
Comment 5 Jasper St. Pierre (not reading bugmail) 2014-08-03 18:46:20 UTC 
I tested with GTK2 and Qt apps and they work fine as well.
Comment 6 drago01 2014-08-03 18:47:23 UTC 
(In reply to comment #5)
> I tested with GTK2 and Qt apps and they work fine as well.

OK, then just the commit message is wrong.
Comment 7 Owen Taylor 2014-08-04 09:30:34 UTC 
(In reply to comment #4)
> (In reply to comment #0)
> 
> > There is no problem with interactive resizing because applications
> > are using the XSync protocol, so we're not painting unless the
> > client has redrawn.
> 
> "because applications are using the Sync protocol" ... that is only true for
> gtk3 apps. Not gtk2, qt, java swing, ...
> 
> You should probably just do it for apps that do use the sync protocol.

This only requires the old sync protocol for the best appearance, not the new enhanced one, so there's more widespread availability. (It's also pretty much fine without the sync protocol since from the point of view of our redrawing, resizing the client window and resizing/redrawing the frame should be atomic.)