gfx/cairo/missing-cairo-clip-init.diff

Wed, 31 Dec 2014 06:09:35 +0100

author
Michael Schloh von Bennewitz <michael@schloh.com>
date
Wed, 31 Dec 2014 06:09:35 +0100
changeset 0
6474c204b198
permissions
-rw-r--r--

Cloned upstream origin tor-browser at tor-browser-31.3.0esr-4.5-1-build1
revision ID fc1c9ff7c1b2defdbc039f12214767608f46423f for hacking purpose.

michael@0 1 diff --git a/gfx/cairo/cairo/src/cairo-gstate.c b/gfx/cairo/cairo/src/cairo-gstate.c
michael@0 2 --- a/gfx/cairo/cairo/src/cairo-gstate.c
michael@0 3 +++ b/gfx/cairo/cairo/src/cairo-gstate.c
michael@0 4 @@ -1841,16 +1841,17 @@ _cairo_gstate_show_text_glyphs (cairo_gs
michael@0 5 transformed_glyphs,
michael@0 6 &num_glyphs,
michael@0 7 transformed_clusters);
michael@0 8
michael@0 9 if (status || num_glyphs == 0)
michael@0 10 goto CLEANUP_GLYPHS;
michael@0 11
michael@0 12 _cairo_gstate_copy_transformed_source (gstate, &source_pattern.base);
michael@0 13 + _cairo_clip_init(&clip);
michael@0 14
michael@0 15 /* For really huge font sizes, we can just do path;fill instead of
michael@0 16 * show_glyphs, as show_glyphs would put excess pressure on the cache,
michael@0 17 * not all components below us correctly handle huge font sizes, and
michael@0 18 * path filling can be cheaper since parts of glyphs are likely to be
michael@0 19 * clipped out. 256 seems like a good limit. But alas, seems like cairo's
michael@0 20 * rasterizer is something like ten times slower than freetype's for huge
michael@0 21 * sizes. So, no win just yet when we're using cairo's rasterizer.

mercurial