When colors are converted to sRGB to render onto the display, make sure
that they are within sRGB gamut limits.
Gamut mapping is implemented according to:
https://drafts.csswg.org/css-color-4/#gamut-mapping
The color-mix-non-srgb-001 test is checking the expected result in
sRGB, which happens to be out of gamut limits, but because the test
is for color-mix and not gamut mapping, I changed the expected
results to the color space of the mix.
The svg reftest now has an increased fuzzy to allow for the final colors
to be gamut mapped. Gamut mapping is dependent of available hardware, so
we can't pin down exact colors for the result.
Differential Revision: https://phabricator.services.mozilla.com/D191083
When colors are converted to sRGB to render onto the display, make sure
that they are within sRGB gamut limits.
Gamut mapping is implemented according to:
https://drafts.csswg.org/css-color-4/#gamut-mapping
The color-mix-non-srgb-001 test is checking the expected result in
sRGB, which happens to be out of gamut limits, but because the test
is for color-mix and not gamut mapping, I changed the expected
results to the color space of the mix.
The svg reftest now has an increased fuzzy to allow for the final colors
to be gamut mapped. Gamut mapping is dependent of available hardware, so
we can't pin down exact colors for the result.
Differential Revision: https://phabricator.services.mozilla.com/D191083
When colors are converted to sRGB to render onto the display, make sure
that they are within sRGB gamut limits.
Gamut mapping is implemented according to:
https://drafts.csswg.org/css-color-4/#gamut-mapping
The color-mix-non-srgb-001 test is checking the expected result in
sRGB, which happens to be out of gamut limits, but because the test
is for color-mix and not gamut mapping, I changed the expected
results to the color space of the mix.
Differential Revision: https://phabricator.services.mozilla.com/D191083
Make use of the new changes in the cssparser that allows 'none' keywords
in color components where allowed. We store the none values as 0.0 (as
per the spec) and mark the components with the flags. This way we don't
have to check anything on the components before doing calculations.
As this is the last part intended to be released for the new [color-4]
changes, I've also enabled the changes on nightly.
Differential Revision: https://phabricator.services.mozilla.com/D170208
Make use of the new changes in the cssparser that allows 'none' keywords
in color components where allowed. We store the none values as 0.0 (as
per the spec) and mark the components with the flags. This way we don't
have to check anything on the components before doing calculations.
As this is the last part intended to be released for the new [color-4]
changes, I've also enabled the changes on nightly.
Differential Revision: https://phabricator.services.mozilla.com/D170208
Computed color values will not be in the correct format, closer to the
one specified by the author. This also means that colors accross the
code are stored now as AbsoluteColor or StyleAbsoluteColor. This allows
color space/gamut information to be available for use.
Some animation related test failures had to be changed, because colors
now has greater precision. Animated a color now causes a lot more
animation updates, which was not initially expected. See the bug for
discussion.
Differential Revision: https://phabricator.services.mozilla.com/D171021
Use new changes from cssparser and use the new lab/lch/oklab/oklch color
formats.
Introduced a new color type AbsoluteColor. It represents any kind of
color that has absolute numerical values. It is also tied to a color
space and therefore can be trivially converted to another color space.
Differential Revision: https://phabricator.services.mozilla.com/D163579
Use new changes from cssparser and use the new lab/lch/oklab/oklch color
formats.
Introduced a new color type AbsoluteColor. It represents any kind of
color that has absolute numerical values. It is also tied to a color
space and therefore can be trivially converted to another color space.
Differential Revision: https://phabricator.services.mozilla.com/D163579
I think this is a good change regardless of other discussion in bug 1552587. If
we decide to move `mColor` to the top-level of the struct that can be done
separately.
Differential Revision: https://phabricator.services.mozilla.com/D32726
We don't have lossy currentcolor in the style system anymore, except for a
single property -moz-font-smoothing-background-color.
I could've converted it into a proper StyleColor and thread down all the
necessary information to the font metrics code.
But it doesn't really seem worth it given it's not exposed to the web, so I just
did the simplest thing, which is making currentcolor compute to transparent to
that specific property.
This patch also removes the stores_complex_colors_lossily code and related,
since now we always can cache computed colors.
Differential Revision: https://phabricator.services.mozilla.com/D26187
We don't have lossy currentcolor in the style system anymore, except for a
single property -moz-font-smoothing-background-color.
I could've converted it into a proper StyleColor and thread down all the
necessary information to the font metrics code.
But it doesn't really seem worth it given it's not exposed to the web, so I just
did the simplest thing, which is making currentcolor compute to transparent to
that specific property.
This patch also removes the stores_complex_colors_lossily code and related,
since now we always can cache computed colors.
Differential Revision: https://phabricator.services.mozilla.com/D26187
Norisz Fay