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 725089 - Cairo context sent to the "draw" signal handler has incorrect clipping with GTK+ 3.10
Cairo context sent to the "draw" signal handler has incorrect clipping with G...
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: .General
3.10.x
Other Linux
: Normal major
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2014-02-24 20:00 UTC by Arun Thondapu
Modified: 2014-08-29 04:16 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
GTK+ test program (2.97 KB, text/plain)
2014-02-24 20:00 UTC, Arun Thondapu 		Details
Output with GTK+ 3.4.2 (11.17 KB, image/png)
2014-02-24 20:08 UTC, Arun Thondapu 		Details
Output with GTK+ 3.10.6 (9.22 KB, image/png)
2014-02-24 20:10 UTC, Arun Thondapu 		Details

Description Arun Thondapu 2014-02-24 20:00:56 UTC 
Created attachment 270177 [details]
GTK+ test program

In GTK+ 3.10.x, the cairo context object that is passed to the "draw" signal handler seems to have wrong clipping area. When there is a hierarchy of widgets, it seems that the cairo object sent in the "draw" signal for the parent no longer is clipped against the children. So drawing done on the parent overwrites the drawing done by the children.

I'm attaching a simple snippet of code (modified from a sample on the GTK+ forums) which demonstrates the changed behavior. When I ran the snippet with GTK+ 3.4.2, the child widget draws on top of the parent, whereas with GTK+ 3.10.6, the child widget gets drawn over by the parent.

This is a major break in behavior and needs to be fixed asap. Please let me know if I'm missing something here.
Comment 1 Arun Thondapu 2014-02-24 20:08:59 UTC 
Created attachment 270179 [details]
Output with GTK+ 3.4.2
Comment 2 Arun Thondapu 2014-02-24 20:10:58 UTC 
Created attachment 270180 [details]
Output with GTK+ 3.10.6
Comment 3 Arun Thondapu 2014-02-24 20:15:51 UTC 
This GTK+ bug is the most likely cause for Eclipse bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=421127
Comment 4 drago01 2014-03-10 19:24:55 UTC 
So from https://bugs.eclipse.org/bugs/show_bug.cgi?id=421127#c40 it seems to be fixed with with https://git.gnome.org/browse/gtk+/commit/?id=e2a83cae0f89945cc24464c21a965fc42affe96a ... is this correct? 

i.e can you confirm that it fixes it (and if it does close this bug and revert the eclipse hack that forces gtk2) ?
Comment 5 Matthias Clasen 2014-03-19 00:09:24 UTC 
gtk 3.11.9 gives identical output to your 3.4 screenshot, so I'll assume this is fixed in master. Leaving this bug open for a backport to 3.10
Comment 6 Matthias Clasen 2014-08-29 04:16:43 UTC 
unlikely to happen at this point