This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget
hack. The old design had several limitations:
* It couldn't handle shadows
* It couldn't handle selections
* It couldn't handle font/color changes in a single text-run
* It couldn't handle decorations (underline, overline, line-through)
Mostly this was a consequence of the fact that it only modified the start and end
of the rendering algorithm, and therefore couldn't distinguish draw calls for different
parts of the text.
This new design is based on a similar principle as DrawTargetCapture, but also passes
down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can
notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us
directly pass data to TextDrawTarget when possible (as is done for shadows and selections).
In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle
changes in font/color mid-text-run (which can happen because of font fallback).
The end result is:
* We handle all shadows natively
* We handle all selections natively
* We handle all decorations natively
* We handle font/color changes in a single text-run
* Although we still hackily intercept draw calls
* But we don't need to buffer commands, reducing total memcopies
In addition, this change integrates webrender's PushTextShadow and PushLine APIs,
which were designed for this use case. This is only done in the layerless path;
WebrenderTextLayer continues to be semantically limited, as we aren't actively
maintaining non-layers-free webrender anymore.
This also doesn't modify TextLayers, to minimize churn. In theory they can be
augmented to support the richer semantics that TextDrawTarget has, but there's
little motivation since the API is largely unused with this change.
MozReview-Commit-ID: 4IjTsSW335h
--HG--
extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
For layers-free mode, we still need to call NotifyInvalidation to trigger
FireDOMPaintEvent. It should be fine to pass an empty rect since we always
take full snapshot for WR.
MozReview-Commit-ID: EzzQi2C5aRQ
--HG--
extra : rebase_source : 81eb63698bd052615c42eebb392e7f771a59f36c
These are all easy cases where an nsXPIDLCString local variable is set via
getter_Copies() and then is only used in ways that nsCStrings can also be used
(i.e. no null checks or implicit conversions to |char*|).
In every case the patch trivially replaces the nsXPIDLCString with an
nsCString. (Also, there are a couple of unused nsXPIDLCString variables that
the patch simply removes.)
In the spec [1], computed value for column-gap is defined as
'as specified, with <length>s made absolute'.
[1] https://drafts.csswg.org/css-multicol-1/#column-gap
MozReview-Commit-ID: IO22V33z8pz
--HG--
extra : rebase_source : 63167965a0e89fd298df3a22a7c5e41ed34dd1e9
As for Gecko we can't interpolate between value with color and value without
color yet (bug 726550) so that transition does not happen for the cases.
As for Servo we can interpolate them but the results are wrong (bug 1390697).
MozReview-Commit-ID: 9T0ELBUP0pL
--HG--
extra : rebase_source : eb0ba751a2d0a1081a7883b7292da6f1d20e4caf
This field will be needed for servo side alias pref handling on the
next patch.
MozReview-Commit-ID: LyH2UwZEvMy
--HG--
extra : rebase_source : f3f921581a0cdcc9c63520b528bd0f1e12568958
CompareCacheHashEntry::mCrit[] is the only case where the nsXPIDLString-ness
was important. The patch adds an explicit SetIsVoid() call to that class's
constructor and changes some null checks to IsVoid() checks.
--HG--
extra : rebase_source : e68befcde4dd098bac2a550bc666eaf3bf1298d7
The reason of the previous failure is we wrongly use default color for drop-shadow
functions that without specified color component. Since this has been resolved in
bug 1388220, we can enable these two tests now.
MozReview-Commit-ID: C3bPcLYQwvW
--HG--
extra : rebase_source : c39d1465658e358110bdccb32649a7fdea4c562c
Bindgen bitfield enums don't work as return values with the Linux 32-bit ABI at
the moment because they wrap the value in a struct.
This causes the Rust side to believe the caller will pass along space for the
struct return value, while C++ believes it's just an integer value.
MozReview-Commit-ID: LY6z7lEKgOp
--HG--
extra : rebase_source : deb9739bd100e2162e7c93d6d45d7029d7793355
Bindgen bitfield enums don't work as return values with the Linux 32-bit ABI at
the moment because they wrap the value in a struct.
This causes the Rust side to believe the caller will pass along space for the
struct return value, while C++ believes it's just an integer value.
MozReview-Commit-ID: 6qqVVfU8Mb2
--HG--
extra : rebase_source : 825985977307b50ae8a80ab182e54a3f7b95eafc
Bindgen bitfield enums don't work as return values with the Linux 32-bit ABI at
the moment because they wrap the value in a struct.
This causes the Rust side to believe the callee expects space for the struct
return value, while C++ believes it's just an integer value.
MozReview-Commit-ID: FRBqlZuMiAR
--HG--
extra : rebase_source : d1b2af4b965c000a5bd8e1792ae166cba5e152a9
Rust was treating this as returning an `Owned` types which uses a struct, while
C++ saw it as just a pointer.
This disagreement violates the Linux 32-bit ABI, and also the pointer was deemed
to be more correct anyway.
MozReview-Commit-ID: AQJkdU02vfh
--HG--
extra : rebase_source : d53d7a395944f65d71f14e540cc6d6bac4582187
nsLayoutUtils::GetDisplayRootFrame() can be quite expensive to call.
By calling this function one level higher (in callers and passing the return
value to callees), we can avoid calling it twice per call to SchedulePaint().
These test cases rely on the behavior that different lengths repeated list can
not be transitioned on Gecko. But it's not clear the behavior is reasonable or
not. The test cases here should not depend on the behavior.
MozReview-Commit-ID: 19vI0TFMzfN
In normal gecko, RefLayer instances also have a transform, which needs
to be propagated to APZ in layers-free mode.
MozReview-Commit-ID: DaEyvpumG9F
--HG--
extra : rebase_source : 694dea8bdaa5a40cf52b2d3e99fdd4c335b6012c
A basic sanity check here seems to produce the correct behaviour but I'm
not at all confident that this will always do the correct thing in more
complex cases or when perspectives are involved. However this is hard to
test and get working without the testing infrastructure up and running
so I'd rather land this simple code first and then dig into the more
complex cases once we have a way to catch regressions.
MozReview-Commit-ID: E4HytiZowEn
--HG--
extra : rebase_source : c7466092298aebf66926e8e0bdf58eb4651f0f19
Currently Gecko treats 'auto' component value as zero for animation.
MozReview-Commit-ID: JBvTFzDw7Xy
--HG--
extra : rebase_source : 618e756bbbb66759eea50a8004740e737f8a94e1
Alexis Beingessner
Wes Kocher
Gian-Carlo Pascutto
Ethan Lin
Wei-Cheng Pan
Xidorn Quan
Cameron McCormack
Sebastian Hengst
Bas Schouten
Carsten "Tomcat" Book
Nicholas Nethercote
Hiroyuki Ikezoe
Nazım Can Altınova
Geoff Brown
Thomas Nguyen
Ting-Yu Lin
Emilio Cobos Álvarez
Jeremy Chen
J. Ryan Stinnett
Ehsan Akhgari
Masayuki Nakano
Bobby Holley
Kartikaya Gupta
Daisuke Akatsuka
Tobias Schneider