GNOME Bugzilla – Bug 737825
gtk_cairo_create() returns a cairo context which is too severely clipped.
Last modified: 2014-10-07 11:34:31 UTC
This breaks both gnumeric and abiword. In gnumeric, I could testn, and for a widget whose allocated size is that the clip extents 1367x549, the clip extents are from 0,0 (which is correct) to 1305,350 (which is bad). This is new with gtk+-3.14. Not sure it is specific to the X11 backend though.
Can you create a testcase that shows this problem, perhaps ?
If you have gnumeric at hand, select some cells including some at the widow bottom, then type Ctrl+C, you'll see the ant walking only near the widget top. Otherwise, I might be able to create a simple testcase during the week-end.
Created attachment 287749 [details] Sample code showin the issue Looks like that the clip region is first initialized with the correct size, but then intersected with the actual widget area before being translated. The unpainted area has the same height that the button. If the button is moved to bottom, the whole area will be painted.
The clipped region is actually translated twice by -window->x, -window->y. The first time at gdkwindow.c:927, and the second in gdk_cairo_create(), line 3070. This can only work properly if both window->x and window->y are 0.
Hmm, looks a bit more involved. If I "fix" the above issue, things work for my widget, but break all others.
I've pushed a fix to 3.14 and master that fixes this. Keep in mind that the testcase only works on X11 and has no chance of ever working on Wayland ue to double buffering.
Thanks for fixing. I know that this will not work on Wayland. Gnumeric might be easily fixed, abiword might just die.