Since the upgrade from 0.24.0 → 0.24.2 I have minor graphical glitches most notably in gtk2 apps. Attached is a screenshot for thunderbird using 0.24.0 (before) and 0.24.2 (after).
Reverting ee500cb2b1abf04ba40a8abfe358f6211d6078d1 fixed those glitches for me.
Created attachment 55872 [details]
Created attachment 55873 [details]
Thanks for the bug report.
Is this affecting the X server or cairo on the client? Ie., after reverting this commit, is it enough to restart thunderbird, or do you have to restart the X server too?
If restarting the X server is necessary, which graphics driver and version are you using?
Also, what version of cairo are you using?
(In reply to comment #3)
> Thanks for the bug report.
> Is this affecting the X server or cairo on the client? Ie., after reverting
> this commit, is it enough to restart thunderbird, or do you have to restart the
> X server too?
> If restarting the X server is necessary, which graphics driver and version are
> you using?
I had to restart the X server. Simply restarting the application was not sufficient. I'm using the intel driver (on a X220 with Sandybridge graphics hardware). The relevant Debian versions are:
I've also attached the Xorg.0.log
Created attachment 55891 [details]
I can't reproduce this bug, not even with the 2.17.0 driver on Sandy Bridge hardware.
Please try the "trapdebug" branch of this repository:
and see if it prints debug spew about invalid trapezoids to the X log file. If it does, please paste some of the spew here.
Also, if you have a second machine and you can ssh in and set a breakpoint on the "print_trap" function to get a backtrace to find out what is generating the invalid traps, that would be helpful.
It turns out that cairo does generate trapezoids where top is strictly above the edges or bottom is strictly below. It doesn't look like it's feasible to consider such trapezoids invalid.
Fixed in master by reverting that commit. An 0.24.4 release will be coming soonish.