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
This changes CreateClippedDrawTarget so that instead of taking
a max size and a transform it just takes a user space rect of
the desired bounds.
This change allows the caller to not worry about the computing
a max size based on the current clip. Instead this responsibility
is lowered into the specific backends.
The main motivation for this work is to allow blob recoordination
to create recordings that don't depend on the current clip.
Some additional benefits are that the API is easier to use and
as can be seen simplifies the SVG masking code because it doesn't
need to track surface offsets manually.
It's also an important step towards removing all the uses of
gfxContext::GetClipExtents which will let us get rid of the separate
clipping stack in gfxContext and help us move off of gfxContext
completely.
Most backend implementations of CreateClippedDrawTarget are relatively
simple. DrawTargetCapture is modified to track the current clip rect
so that it can create a new DrawTargetCapture of the appropriate size
without needing to worry about lazy resolution.
Differential Revision: https://phabricator.services.mozilla.com/D33363
--HG--
extra : moz-landing-system : lando
This changes CreateClippedDrawTarget so that instead of taking
a max size and a transform it just takes a user space rect of
the desired bounds.
This change allows the caller to not worry about the computing
a max size based on the current clip. Instead this responsibility
is lowered into the specific backends.
The main motivation for this work is to allow blob recoordination
to create recordings that don't depend on the current clip.
Some additional benefits are that the API is easier to use and
as can be seen simplifies the SVG masking code because it doesn't
need to track surface offsets manually.
It's also an important step towards removing all the uses of
gfxContext::GetClipExtents which will let us get rid of the separate
clipping stack in gfxContext and help us move off of gfxContext
completely.
Most backend implementations of CreateClippedDrawTarget are relatively
simple. DrawTargetCapture is modified to track the current clip rect
so that it can create a new DrawTargetCapture of the appropriate size
without needing to worry about lazy resolution.
Differential Revision: https://phabricator.services.mozilla.com/D33363
--HG--
extra : moz-landing-system : lando
Since now most CSS transform related bugs are fixed, it's clear that the
purpose of nsSVGUtils::GetTransformMatrixInUserSpace() should solely be to
replace SVGElement::PrependLocalTransformsTo(eUserSpaceToParent).
After fixing Bug 972041, the only other usecase (Bug 1247218) no longer exists.
OTOH, there is a problem when the parent has a viewbox transform, in that case,
SVGElement::PrependLocalTransformsTo() doesn't include it, but
nsLayoutUtils::GetTransformToAncestor() does.
In fact, it's much easier to compute the transform matrix directly based on
the implementation of nsDisplayTransform::GetResultingTransformMatrixInternal(),
which is also the function internally called by nsLayoutUtils::GetTransformToAncestor().
In particular, we don't need to look at 3D stuff since our matrix is inherently 2D.
Differential Revision: https://phabricator.services.mozilla.com/D28970
--HG--
extra : moz-landing-system : lando
SVGElement::PrependLocalTransformsTo doesn't take CSS transform into
account, we should use nsIFrame::GetTransformMatrix instead.
Differential Revision: https://phabricator.services.mozilla.com/D27659
--HG--
extra : moz-landing-system : lando
Additionally, this patch makes `nsFrame.h` stop including `nsIPresShell.h`
and makes each users include `mozilla/PresShell.h` instead. So, this improves
rebuild performance of `nsIPresShell.h` (and `mozilla/PresShell.h` in the
future).
Note that due to `nsIFrame::PresShell()`, `mozilla::` prefix is necessary for
`PresShell` in a lot of classes which are derived from `nsIFrame` even in
`.cpp` files.
Differential Revision: https://phabricator.services.mozilla.com/D27476
--HG--
extra : moz-landing-system : lando
This lets us restrict the size of the mask surface that we allocate
to the destination tile size. This gives a large performance
improvement.
It also includes some miscelanous fixes to the CreateClippedDrawTarget
code path.
Differential Revision: https://phabricator.services.mozilla.com/D21750
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
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
The reason of this change is the same as for Part 2, except this commit fixes
nsSVGMaskFrame::GetMaskForMaskedFrame rather than PaintSVG.
MozReview-Commit-ID: DS0eG6eKDgs
The DrawResult return was not in fact anything to do with the success or
failure of that method, but was actually passing out a very specific piece of information
about the success or failure of any imagelib drawing that may not have occurred
under the various PaintSVG calls.
The signature of PaintSVG is changed from
DrawResult PaintSVG(...., uint32 flags);
to
void PaintSVG(...., imgDrawingParams& aPackage);
imgDrawingParams wraps DrawResult and imgIContainer::FLAG_* as a pack, pass through
PaintSVG to imagelib draw calls under beneath.
MozReview-Commit-ID: IOq2evUAOQF
The reason of this change is the same as for Part 2, except this commit fixes
nsSVGMaskFrame::GetMaskForMaskedFrame rather than PaintSVG.
MozReview-Commit-ID: DS0eG6eKDgs
--HG--
extra : rebase_source : 696bf495edc98a390f49ff0638165724521460b1
extra : source : 95f38c2c8b57134504e7fbe03d1637866e3e65ba
The DrawResult return was not in fact anything to do with the success or
failure of that method, but was actually passing out a very specific piece of information
about the success or failure of any imagelib drawing that may not have occurred
under the various PaintSVG calls.
The signature of PaintSVG is changed from
DrawResult PaintSVG(...., uint32 flags);
to
void PaintSVG(...., imgDrawingParams& aPackage);
imgDrawingParams wraps DrawResult and imgIContainer::FLAG_* as a pack, pass through
PaintSVG to imagelib draw calls under beneath.
MozReview-Commit-ID: IOq2evUAOQF
--HG--
extra : rebase_source : 66c9a9e391c2f9e142575f42fd47b37334ec5752
extra : source : 97a08873177c0f18edffdb1b5589c77843a50553
