I was working around stopDelta always being 0 for conic-gradient since it doesn't have a gradient line and disabled the essential normalization code. This patch fixes the definition of stopDelta for conic gradients and re-enables the normalization code.
Differential Revision: https://phabricator.services.mozilla.com/D65994
--HG--
extra : moz-landing-system : lando
gfx::Color is currently misused in many places. The DrawTargets expect
the color space to be in device space, e.g. what we are actually going
to draw using. Everything sitting above generally deals with sRGB, as
specified in CSS. Sometimes we missed the conversion from sRGB to device
space when issuing draw calls, and similarly sometimes we converted the
color to device space twice.
This patch splits the type in two. sRGBColor and DeviceColor now
represent sRGB and device color spaces respectively. DrawTarget only
accepts DeviceColor, and one can get a DeviceColor from an sRGBColor via
the ToDeviceColor helper API. The reftests now pass with color
management enabled for everything (e.g. CSS) instead of just tagged
raster images.
There will be a follow up patch to enable color management everywhere by
default on all supported platforms.
Differential Revision: https://phabricator.services.mozilla.com/D64771
--HG--
extra : moz-landing-system : lando
The gradient code is the only one that does a really weird thing with
LengthPercentage values, by getting the percentage and length separately and
turning the length into a percentage relative to the line length (which is in
device pixels).
This won't work once we have min() / max() / etc. in CSS (as we can't access
the length and percentage components separately, as which one you choose may
depend on the percentage basis). So instead of that, use the regular
ResolveToCssPixels there are lengths involved.
We change a bit the surrounding code to work in CSS pixels, so as to avoid
unneeded CSS -> device pixel conversions.
Differential Revision: https://phabricator.services.mozilla.com/D60159
--HG--
extra : moz-landing-system : lando
The gradient code is the only one that does a really weird thing with
LengthPercentage values, by getting the percentage and length separately and
turning the length into a percentage relative to the line length (which is in
device pixels).
This won't work once we have min() / max() / etc. in CSS (as we can't access
the length and percentage components separately, as which one you choose may
depend on the percentage basis). So instead of that, use the regular
ResolveToCssPixels there are lengths involved.
We change a bit the surrounding code to work in CSS pixels, so as to avoid
unneeded CSS -> device pixel conversions.
Differential Revision: https://phabricator.services.mozilla.com/D60159
--HG--
extra : moz-landing-system : lando
This doesn't clean up all that much, yet, but it's a step in the right
direction.
Differential Revision: https://phabricator.services.mozilla.com/D29168
--HG--
extra : moz-landing-system : lando
In particular, split the computation of the resolved stops into its own
function, and inside of it, the switch computing the specified length of a
gradient too, since in bug 1352643 there'll be two of those.
MozReview-Commit-ID: FSYzzAxNBbV
--HG--
extra : rebase_source : 9b3a0dc89c5c107adfa9a5e3743a709d3cac240c
To correctly apply pixel snapping during display list construction we would need to snap each tile of a repeated gradient individually. It's preferrable to do this in WebRender rather than decompose gradients into many display items.
The core of this change is in gfxContext.*:
- change gfxContext::CurrentMatrix() and gfxContext::SetMatrix() to
return and take a Matrix respectively, instead of converting to
and from a gfxMatrix (which uses doubles). These functions therefore
will now match the native representation of the transform in gfxContext.
- add two new functions CurrentMatrixDouble() and SetMatrixDouble() that
do what the old CurrentMatrix() and SetMatrix() used to do, i.e.
convert between the float matrix and the double matrix.
The rest of the change is just updating the call sites to avoid round-
tripping between floats and doubles where possible. Call sites that are
hard to fix are migrated to the new XXXDouble functions which preserves
the existing behaviour.
MozReview-Commit-ID: 5sbBpLUus3U
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
For layers-full mode, we set the backface-visibility to visible because
visibility would be handled by FLB and layers.
MozReview-Commit-ID: CUbeUabfC7K