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?
(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.
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?
Filed bug 594019.
You need to log in before you can comment on or make changes to this bug.