gfx/cairo/missing-cairo-clip-init.diff@97036ab72558 (annotated)
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.
| 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. |
