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 is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando
This is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando
Per our discussion, this patch splits out the state management bits of
WebRenderLayerManager, allowing for them to be maintained per-document.
Differential Revision: https://phabricator.services.mozilla.com/D13577
--HG--
extra : moz-landing-system : lando
Badly-behaved consumers of DrawTargetRecording can trigger recording of
draw calls that will fail to allocate required draw targets when the
recording is replayed. This patch tries to guard against this by
detecting these situations at record-time rather than crashing at
replay-time. When such a situation is detected, it will crash (for
content processes, to catch such scenarios) or gracefully fail (for
other processes).
Differential Revision: https://phabricator.services.mozilla.com/D11527
--HG--
extra : moz-landing-system : lando
The clipping code uses gfxContext::GetClipExtents which calls gfxContext::GetDeviceOffset
and DrawTarget::GetSize. The former was previously not being intialized, while the latter
was explicitly unimplemented. This patch fixes both of those facts.
Otherwise, enabling this functionality has been made trivial by several upstream patches
in webrender (the most recent being glenn's work on unifying shadows which eliminated
the buggy text-shadow shader code that was blocking this).
MozReview-Commit-ID: B1AlG3o4XQS
--HG--
extra : rebase_source : 2043c9c781f507c5d02041420145b1a5c59c0bb2
This function doesn't use any StackingContextHelper state anymore.
We should make what it does clearer and move it to a better place.
--HG--
extra : rebase_source : 1727be9657169547d842ec9b6887837abedbefdf
For draw target, the initial clip region should be the draw target's size.
MozReview-Commit-ID: 2z2EobkYFs2
--HG--
extra : rebase_source : 9631cf189330b089992b8458113800ea9a3fd4a0
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
This does 3 things that were all a bit too intermixed to split out cleanly:
1. Teaches TextDrawTarget to handle rectangular clips (while also completely
forbidding other ones). This is necessary to handle how gecko "overdraws"
decorations with clips to create the illusion of continuous lines when they're
actually made out of multiple lines, possibly from different display items
with different lines. Previously gecko *was* handing these clips to
TextDrawTarget to use these clips, but we were just ignoring them.
This is also necessary work to support partial glyphs natively (which apply
rectangular clips to glyphs). Also note that this currently causes a bug
in webrender if combined with zero-blur shadows, but it's not a regression
since we already mishandle clipped decorations. I will work on fixing this
upstream.
2. Changes the intermediate representation of lines from the old webrender
format to a rect-based one. This is in preperation for webrender adopting
that format in a future update.
3. Changes the way wavy lines are processed, correcting some errors in the
old wavy line bindings that lead to them being positioned incorrectly. Also
introduces a wavyLineThickness property that the will be required in a
future webrender update. Wavy lines are unlike any other line, so it's
ultimately desirable to distinguish them.
The net result of these changes is that a companion upstream change (webrender#1923)
will make decoration rendering nearly identical to gecko, and much nicer.
However the clipped shadows issue will need to be seperately resolved before
actually closing this issue.
MozReview-Commit-ID: 6O2wLA6bU3C
--HG--
extra : rebase_source : 17254c45145229b75f77f87f85874e66e6edd05e
This does 3 things that were all a bit too intermixed to split out cleanly:
1. Teaches TextDrawTarget to handle rectangular clips (while also completely
forbidding other ones). This is necessary to handle how gecko "overdraws"
decorations with clips to create the illusion of continuous lines when they're
actually made out of multiple lines, possibly from different display items
with different lines. Previously gecko *was* handing these clips to
TextDrawTarget to use these clips, but we were just ignoring them.
This is also necessary work to support partial glyphs natively (which apply
rectangular clips to glyphs). Also note that this currently causes a bug
in webrender if combined with zero-blur shadows, but it's not a regression
since we already mishandle clipped decorations. I will work on fixing this
upstream.
2. Changes the intermediate representation of lines from the old webrender
format to a rect-based one. This is in preperation for webrender adopting
that format in a future update.
3. Changes the way wavy lines are processed, correcting some errors in the
old wavy line bindings that lead to them being positioned incorrectly. Also
introduces a wavyLineThickness property that the will be required in a
future webrender update. Wavy lines are unlike any other line, so it's
ultimately desirable to distinguish them.
The net result of these changes is that a companion upstream change (webrender#1923)
will make decoration rendering nearly identical to gecko, and much nicer.
However the clipped shadows issue will need to be seperately resolved before
actually closing this issue.
MozReview-Commit-ID: 6O2wLA6bU3C
--HG--
extra : rebase_source : 98da45bc7f2eaabd63ae226c505cb1580b5c8500
Also cleans up a bunch of TextDrawTarget code as fallout.
This is a significant perf win for textFrames.
MozReview-Commit-ID: J1BDkXZdvnc
--HG--
extra : rebase_source : 5a0769a53cadb55a074cfe5d718e259401fa7028
This adds fallbacks for:
* synthetic bold
* synthetic italics
* text-writing-modes
This also removes an old hack to make synthetic italics less broken.
This also prevents special opacity handling for color fonts so that webrender
gets that information.
MozReview-Commit-ID: DKiTUBR6hzy
--HG--
extra : rebase_source : 22b445d40ee46bb09d4325828a8e959d3da7a9c7
Selections in gecko are used to hack in style changes to subsets of text frames.
Mostly this works fine because decorations don't care where they are, and
textRunFragments already exist to do style changes midFrame. However we mishandled
shadows because we were assuming they applied to the entire run, which isn't
the case when shadows are involved.
Applying shadows to everything was desirable because the way nsTextFrame is written,
it's difficult for us to associate the glyphs and decorations with a "range".
However the selections iterator provides a natural grouping, so we use that.
The result is that TextDrawTarget effectively becomes an array of what TextDrawTarget
used to be (now called SelectedTextRunFragment). Everything else is just fallout
of this change.
MozReview-Commit-ID: 5GWPruo6daW
--HG--
extra : rebase_source : 8e1c1d61e43151ee6651f8c6cfbcb0912262df56
Narcis Beleuzu
Jeff Muizelaar
Nicolas Silva
Doug Thayer
Ciure Andrei
Matt Woodrow
Timothy Nikkel
Sylvestre Ledru
Kartikaya Gupta
Jeff Muizelaar
Andreea Pavel
Lee Salzman
Alexis Beingessner
Sebastian Hengst
Tristan Bourvon
Miko Mynttinen
Jamie Nicol
Kevin Chen
Ethan Lin
Markus Stange
Daniel Holbert
Attila Craciun
Ryan VanderMeulen