gfx/cairo/quartz-first-stop.patch@97036ab72558 (annotated)
gfx/cairo/quartz-first-stop.patch
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-quartz-surface.c b/gfx/cairo/cairo/src/cairo-quartz-surface.c |
| michael@0 | 2 | --- a/gfx/cairo/cairo/src/cairo-quartz-surface.c |
| michael@0 | 3 | +++ b/gfx/cairo/cairo/src/cairo-quartz-surface.c |
| michael@0 | 4 | @@ -690,31 +690,51 @@ ComputeGradientValue (void *info, const |
| michael@0 | 5 | } |
| michael@0 | 6 | |
| michael@0 | 7 | static const float gradient_output_value_ranges[8] = { |
| michael@0 | 8 | 0.f, 1.f, 0.f, 1.f, 0.f, 1.f, 0.f, 1.f |
| michael@0 | 9 | }; |
| michael@0 | 10 | static const CGFunctionCallbacks gradient_callbacks = { |
| michael@0 | 11 | 0, ComputeGradientValue, (CGFunctionReleaseInfoCallback) cairo_pattern_destroy |
| michael@0 | 12 | }; |
| michael@0 | 13 | +/* Quartz will clamp input values to the input range. |
| michael@0 | 14 | + |
| michael@0 | 15 | + Our stops are all in the range 0.0 to 1.0. However, the color before the |
| michael@0 | 16 | + beginning of the gradient line is obtained by Quartz computing a negative |
| michael@0 | 17 | + position on the gradient line, clamping it to the input range we specified |
| michael@0 | 18 | + for our color function, and then calling our color function (actually it |
| michael@0 | 19 | + pre-samples the color function into an array, but that doesn't matter just |
| michael@0 | 20 | + here). Therefore if we set the lower bound to 0.0, a negative position |
| michael@0 | 21 | + on the gradient line will pass 0.0 to ComputeGradientValue, which will |
| michael@0 | 22 | + select the last color stop with position 0, although it should select |
| michael@0 | 23 | + the first color stop (this matters when there are multiple color stops with |
| michael@0 | 24 | + position 0). |
| michael@0 | 25 | + |
| michael@0 | 26 | + Therefore we pass a small negative number as the lower bound of the input |
| michael@0 | 27 | + range, so this value gets passed into ComputeGradientValue, which will |
| michael@0 | 28 | + return the color of the first stop. The number should be small because |
| michael@0 | 29 | + as far as I can tell, Quartz pre-samples the entire input range of the color |
| michael@0 | 30 | + function into an array of fixed size, so if the input range is larger |
| michael@0 | 31 | + than needed, the resolution of the gradient will be unnecessarily low. |
| michael@0 | 32 | +*/ |
| michael@0 | 33 | +static const float nonrepeating_gradient_input_value_range[2] = { -0.001f, 1.f }; |
| michael@0 | 34 | |
| michael@0 | 35 | static CGFunctionRef |
| michael@0 | 36 | CreateGradientFunction (const cairo_gradient_pattern_t *gpat) |
| michael@0 | 37 | { |
| michael@0 | 38 | cairo_pattern_t *pat; |
| michael@0 | 39 | - float input_value_range[2] = { 0.f, 1.f }; |
| michael@0 | 40 | |
| michael@0 | 41 | if (_cairo_pattern_create_copy (&pat, &gpat->base)) |
| michael@0 | 42 | /* quartz doesn't deal very well with malloc failing, so there's |
| michael@0 | 43 | * not much point in us trying either */ |
| michael@0 | 44 | return NULL; |
| michael@0 | 45 | |
| michael@0 | 46 | return CGFunctionCreate (pat, |
| michael@0 | 47 | 1, |
| michael@0 | 48 | - input_value_range, |
| michael@0 | 49 | + nonrepeating_gradient_input_value_range, |
| michael@0 | 50 | 4, |
| michael@0 | 51 | gradient_output_value_ranges, |
| michael@0 | 52 | &gradient_callbacks); |
| michael@0 | 53 | } |
| michael@0 | 54 | |
| michael@0 | 55 | static void |
| michael@0 | 56 | UpdateLinearParametersToIncludePoint(double *min_t, double *max_t, CGPoint *start, |
| michael@0 | 57 | double dx, double dy, |
