gfx/cairo/missing-cairo-clip-init.diff@97036ab72558
gfx/cairo/missing-cairo-clip-init.diff
Tue, 06 Jan 2015 21:39:09 +0100
- author
- Michael Schloh von Bennewitz <michael@schloh.com>
- date
- Tue, 06 Jan 2015 21:39:09 +0100
- branch
- TOR_BUG_9701
- changeset 8
- 97036ab72558
- permissions
- -rw-r--r--
Conditionally force memory storage according to privacy.thirdparty.isolate;
This solves Tor bug #9701, complying with disk avoidance documented in
https://www.torproject.org/projects/torbrowser/design/#disk-avoidance.
1 diff --git a/gfx/cairo/cairo/src/cairo-gstate.c b/gfx/cairo/cairo/src/cairo-gstate.c
2 --- a/gfx/cairo/cairo/src/cairo-gstate.c
3 +++ b/gfx/cairo/cairo/src/cairo-gstate.c
4 @@ -1841,16 +1841,17 @@ _cairo_gstate_show_text_glyphs (cairo_gs
5 transformed_glyphs,
6 &num_glyphs,
7 transformed_clusters);
9 if (status || num_glyphs == 0)
10 goto CLEANUP_GLYPHS;
12 _cairo_gstate_copy_transformed_source (gstate, &source_pattern.base);
13 + _cairo_clip_init(&clip);
15 /* For really huge font sizes, we can just do path;fill instead of
16 * show_glyphs, as show_glyphs would put excess pressure on the cache,
17 * not all components below us correctly handle huge font sizes, and
18 * path filling can be cheaper since parts of glyphs are likely to be
19 * clipped out. 256 seems like a good limit. But alas, seems like cairo's
20 * rasterizer is something like ten times slower than freetype's for huge
21 * sizes. So, no win just yet when we're using cairo's rasterizer.
