[cairo] Firefox/Gtk3 - possible cairo clipping bug

[Uli Schlachter]

Hi,

On 17.07.2013 16:18, Martin Stransky wrote:
> I work on Firefox Gtk3 port and there's a strange bug [1][2]. It looks 
> like in some case cairo_clip() does not work. The code is from 
> _gtk_theming_background_paint_color() [3] and looks like:
> 
> _gtk_rounded_box_path (&clip_box, cr);
> cairo_clip (cr);
> gdk_cairo_set_source_rgba (cr, &bg->bg_color);
> cairo_paint (cr);
> 
> _gtk_rounded_box_path creates a rounded box for gtk_entry element. When 
> the code is called from a simple testcase, cairo_clip() works and the 
> cairo_paint() is clipped by the area, i.e. gtkEntry background is rendered.
> 
> When tha same code is called from Firefox, cairo_clip() does not take 
> effect and whole surface is filled by the color.

Doesn't Mozilla bundle its own copy of cairo? How does this even work?
Firefox would use its own copy of cairo while Gtk3 links against libcairo and
uses another version.

AFAIR there is some pre-processor magic to rename the symbols of the bundled
cairo copy, but does anything make sure that no cairo state is passed between
the bundled and the system cairo copy?

(I don't think that this has anything to do with the issue at hand, because I
would expect crashes if something goes wrong here. This question just came to my
mind.)

> Do you guys have an idea where should I look at? Any debugging hints?
[...]

If you think that you are seeing a cairo issue, it might be interesting to know
which cairo version you are using and if you also tried older/newer cairo versions.

Also, assuming you are using cairo-xlib, it might be worth a try to set
CAIRO_DEBUG=xrender-version=-1.-1 or CAIRO_DEBUG=xrender-version=0.0 in the
environment. This should cause quite different code paths to be used inside of
cairo.

However, in comment [0] this doesn't sound like a cairo bug. I would be really
surprised if cairo_clip() somehow accidentally loses a clip and would start
producing a "no-clip" result.

Perhaps it would be a good start to step through the last cairo_clip() call and
check how the clip got lost. This code is quite simple and basically just calls
into _cairo_clip_intersect_path() which handles all complicated cases by copying
the path and adding to the list of clip paths. Not much that can go wrong here...

Cheers,
Uli

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=877606#c7
-- 
"For saving the Earth.. and eating cheesecake!"