This ensures they're clamped on Animated -> sRGB conversion, and in the
future we'll have to implement different color spaces so we'll need to
use it anyways.
Differential Revision: https://phabricator.services.mozilla.com/D149792
This ensures they're clamped on Animated -> sRGB conversion, and in the
future we'll have to implement different color spaces so we'll need to
use it anyways.
Differential Revision: https://phabricator.services.mozilla.com/D149792
Build errors fixed here:
layout/painting/DottedCornerFinder.cpp:33:1: error: no template named 'nsTHashMap'
(and similar for layout/painting/DashedCornerFinder.cpp)
* Fixed by including nsTHashMap.h
layout/painting/WindowRenderer.cpp:186:38: error: use of undeclared identifier 'Rect'; did you mean 'gfx::Rect'?
layout/painting/WindowRenderer.cpp:111:18: error: unknown type name 'PersistentBufferProvider'; did you mean 'layers::PersistentBufferProvider'?
(and more similar errors for e.g. `PersistentBufferProviderBasic::Create`, etc.)
* Fixed by adding 'using' statements.
layout/painting/WindowRenderer.cpp:117:8: error: use of undeclared identifier 'gfxPlatform'
layout/painting/WindowRenderer.cpp:148:57: error: member access into incomplete type 'mozilla::dom::AnimationEffect'
layout/painting/WindowRenderer.cpp:150:16: error: incomplete type 'mozilla::EffectSet' named in nested name specifier
layout/painting/WindowRenderer.cpp:211:26: error: member access into incomplete type 'mozilla::nsDisplayList'
* Fixed by including these types' headers.
layout/painting/HitTestInfo.cpp:67:32: error: use of undeclared identifier 'CompositorHitTestFlags'; did you mean 'gfx::CompositorHitTestFlags'?
* Fixed by adding 'using' statement.
layout/painting/nsCSSRenderingGradients.cpp:772:26: error: incomplete type 'nsLayoutUtils' named in nested name specifier
* Fixed by including nsLayoutUtils.h
layout/painting/nsCSSRenderingGradients.h:106:29: error: unknown type name 'gfxPattern'
* Fixed with a forward-decl.
layout/painting/nsCSSRenderingGradients.h:107:30: error: unknown type name 'gfxRect'
* Fixed with an include (can't use a forward-decl here; gfxRect is a typedef and hence can't really be forward-declared).
Differential Revision: https://phabricator.services.mozilla.com/D138219
There are no code changes, only #include changes.
It was a fairly mechanical process: Search for all "AUTO_PROFILER_LABEL", and in each file, if only labels are used, convert "GeckoProfiler.h" into "ProfilerLabels.h" (or just add that last one where needed).
In some files, there were also some marker calls but no other profiler-related calls, in these cases "GeckoProfiler.h" was replaced with both "ProfilerLabels.h" and "ProfilerMarkers.h", which still helps in reducing the use of the all-encompassing "GeckoProfiler.h".
Differential Revision: https://phabricator.services.mozilla.com/D104588
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