nsSVGMaskFrame::ComputeMaskAlpha calls ConvertImageDataToLinearRGB unconditionally

RESOLVED INVALID

Status

()

Core
SVG
RESOLVED INVALID
8 years ago
8 years ago

People

(Reporter: mstange, Unassigned)

Tracking

({perf})

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 years ago
nsSVGMaskFrame::ComputeMaskAlpha calls ConvertImageDataToLinearRGB regardless of the mask's color-interpolation-filter - is that correct?

After bug 586954 that call is one of the most expensive parts of mask drawing. It would be nice if one could avoid it by setting an appropriate color-interpolation-filters value on the mask.
Spec says:

  For any graphics object that is used as a mask, the mask value at any point
  is computed from the color channel values and alpha channel value as follows.
  A linear luminance value is computed from the color channel values. This can
  be done, for example, by first converting the original image color values
  (potentially in the sRGB color space) to the linear RGB color space (see
  Rendering properties). Then, using non-premultiplied linear RGB color values,
  apply the luminance-to-alpha coefficients (as defined in the ‘feColorMatrix’
  filter primitive) to convert the linear RGB color values to linear luminance
  values. If the graphics object also includes an alpha channel, then the
  computed linear luminance value is multiplied by the corresponding alpha
  value to produce the mask value.

(SVG 1.1, section 14.4 paragraph 6.)  So yes, unconditionally using LinearRGB is correct here.

On the other hand, perhaps we should consider handcoding an sRGB version of the luminance calculation, so that we can avoid doing two passes?
(Reporter)

Comment 2

8 years ago
(In reply to comment #1)
>   by first converting the original image color values
>   (potentially in the sRGB color space) to the linear RGB color space

ConvertImageDataToLinearRGB assumes that the input data is sRGB, but "*potentially* in the sRGB color space" sounds to me like that may not necessarily be the case. 

> On the other hand, perhaps we should consider handcoding an sRGB version of the
> luminance calculation, so that we can avoid doing two passes?

Sounds good.
If we supported color-interpolation the colour could be in a different colour space but we don't currently so everything is always sRGB.

color-interpolation-filters is just for filters and has no effect on masks.
(Reporter)

Comment 4

8 years ago
Ah, that makes sense, thanks.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INVALID
Well, do we still want a bug on making the calculation here one-pass?
(Reporter)

Comment 6

8 years ago
Filed bug 594019.
You need to log in before you can comment on or make changes to this bug.