Re: Firefox/Gtk3 - possible cairo clipping bug
Uli Schlachter <[email protected]>
| Newsgroups | gmane.comp.lib.cairo |
|---|---|
| Message-ID | <[email protected]> |
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!" -- cairo mailing list [email protected] http://lists.cairographics.org/mailman/listinfo/cairo