We were getting the proper app units value for transform matrix offset before
Bug 1384656. But after that bug we started using GetCalcValue() method and
it wasn't converting length to app units and this was cousing to miscalculate
translate functions in transform property.
MozReview-Commit-ID: HHlrSg00252
--HG--
extra : rebase_source : dfc96f7905a8b501c0427519bbe5c2cb5010424e
Change the interface to GetAlowsInline to take an nsISupports* instead
of a string, and pass the nsIScriptElement directly. If we don't have an
element, then pass nullptr or the mock string created as an
nsISupportsString.
MozReview-Commit-ID: pgIMxtplsi
--HG--
extra : rebase_source : 4691643bb67ff6c78a74a4886a04c4816cff6219
Put mEffectsBounds in nsDisplyaSVGEffect does not really make sense, since only
nsDisplayFilter need it.
MozReview-Commit-ID: KSvDspZJcMP
--HG--
extra : rebase_source : 9d2f994b40e82e7146358932fbebbc60a4ca01c6
extra : source : cfd8d564c0198239eb029e4984d75a692bd9f9ca
This method can be extremely hot, so we need to remove all sources of XPCOM
overhead from it. This includes the usages of weak pointers (thanks to the
previous parts), refcounting, and QueryInterface.
I kept the callers hold the selection controller alive by assigning the
return value to an nsCOMPtr in places where the methods called on it could
have a remote chance of messing with the lifetime of objects.
We need to create a WebRenderAnimationData item in order to preserve the
animation id on the frame - this allows to re-use the same animation id
over multiple display list building phases.
MozReview-Commit-ID: 5Uj5sv6FUgt
This patch move common canvas interfaces out of layer. So I create a
base class CanvasRenderer which move interfaces from CanvasLayer.
CopyableCanvasRenderer from CopyableCanvasLayer, ClientCanvasRenderer
from ClientCanvasLayer and WebRenderCanvasRenderer from
WebRenderCanvasLayer. And finally, WebRenderCanvasRendererSync for the
non layers free mode and WebRenderCanvasRendererAsync for the layers
free mode.
Summary all changes in this patch.
* Move class CanvasLayer::Data to CanvasRenderer.h and rename it to
CanvasInitializeData. Because this class not only use by layer but also
* Move BasicCanvasLayer::UpdateSurface to
CopyableCanvasRenderer::ReadbackSurface.
* CanvasClient::Update now accepts ShareableCanvasRenderer as parameter.
not CanvasLayer.
use by layers-free mode. Move it out of layer's class makes more sense.
* Add InitializeCanvasRenderer in the canvas related classes to
initialize CanvasRenderer without involved layer.
* All canvas layer has function "CreateCanvasRendererInternal" that
initialize corresponding CanvasRenderer.
* Description of all CanvasRenderer classes:
** CanvasRenderer: Based classes.
** CopyableCanvasRenderer: Can readback canvas content to a
SourceSurface. Use by BasicCanvasLayer.
** ShareableCanvasRenderer: Provide IPC capabilities that allow sending
canvas content over IPC. This is pure virtual class because the IPC handling is
different in different LayerManager.
** ClientCanvasRenderer: Implement IPC handling for ClientLayerManager.
Use by ClientCanvasLayer.
** WebRenderCanvasRenderer: Implement IPC handling for
WebRenderLayerManager.
** WebRenderCanvasRendererSync: Use by WebRenderCanvasLayer.
** WebRenderCanvasRendererAsync: Use by layers-free mode in WebRender.
class diagram shows below:
+--------------+
|CanvasRenderer|
+-------+------+
^
|
+----------------------+
|CopyableCanvasRenderer|
+----------------------+
^
|
+-----------+-----------+
|ShareableCanvasRenderer|
+-----+-----------------+
^ ^
+-------------+ +-------+
| |
+--------------------+ +---------+-------------+
|ClientCanvasRenderer| |WebRenderCanvasRenderer|
+--------------------+ +--------+--+-----------+
^ ^
+-----------------------+ +----+
| |
+-------------+-------------+ +-------------+--------------+
|WebRenderCanvasRendererSync| |WebRenderCanvasRendererAsync|
+---------------------------+ +----------------------------+
MozReview-Commit-ID: 5hqQ19W169r
In while-loop [1],
1. The first SetMatrix call that I remvoed in this patch is totally useless,
we can just pass initialMatrix to contextPaint, instead of set initialMatrix
to aContenxt and read back from aContext and then pass it to contextPaint.
2. This function, SVGTextFrame::PaintSVG, is the only caller of
SetupStrokeGeometry, and it does not need SetupStrokeGeometry to setup matrix at
all, since it will be overwritten the transform matrix of aContext at several
lines below[2].
[1]
https://hg.mozilla.org/mozilla-central/file/5115e2dea29a/layout/svg/SVGTextFrame.cpp#l3658
[2]
https://hg.mozilla.org/mozilla-central/file/5115e2dea29a/layout/svg/SVGTextFrame.cpp#l3685
MozReview-Commit-ID: AlKQh4abbpa
--HG--
extra : rebase_source : e0dfd66ff25be0d7cffadecf9e3333bba10cff9b
(This patch is not relative to performance)
Rename this function since it has not relation with cario at all.
MozReview-Commit-ID: DHvrsVZAJ7B
--HG--
extra : rebase_source : 4994c9058bd93c7d6671e57ce7f204185e679a1a
Unless we need to draw stroke of glyphs, which will change the state of the
target context, we only need to save & restore transform matrix of the target
context.
MozReview-Commit-ID: LLKnxrKrDaT
--HG--
extra : rebase_source : 1226c48d283a04cb0ea6959f12fd6938fece49d2
nsDisplaySVGText::Paint calls SVGTextFrame::PaintSVG, and we already save/restore
context state in SVGTextFrame::PaintSVG.
I also filed Bug 1385929 to find a solution to prevent duplicated
gfxContext::Save/Restore.
MozReview-Commit-ID: 4WxdFZzvmvF
--HG--
extra : rebase_source : 752d5d027776538edc1ab043ad2e90e1de22a079
We have to set mHaveNonAnimationRestyles if we have attributes changed
(note: we increase the animation generation only if mHaveNonAnimationRestyles
is set). Attributes changed may create a new transition, and we use the
animation generation as the order of the transition, so
Element::GetAnimations() can return transitions with correct order.
Besides, I think ContentStateChanged() will not trigger a new
transition, so we don't need to make mHaveNonAnimationRestyles there.
MozReview-Commit-ID: J5XgW8nqeLH
--HG--
extra : rebase_source : 24c4b4364935fc5a4b8437f119cbf93035262684
The patch provides FFI access to Gecko's SeenPtrs type from Rust, in order to
record what has already been measured when measuring Arcs. (The SeenPtrs must
be initialized on the Gecko side because the same table is reused for measuring
all Elements within a window, because Elements can share ComputedValues.) I
have confirmed with DMD that this is working correctly.
The patch also introduces MallocSizeOfRepeats, which is like MallocSizeOf but
takes a SizeOfState, which holds a SeenPtrs table.
MozReview-Commit-ID: DHS8zvCsEdQ
--HG--
extra : rebase_source : acf4d7909abf6ceb1719331ccf2e33137eb6dc91
When display style is changed from 'none' to other in animation-only restyle
we need to resolve descendant elements' style that were in the display:none
subtree.
Three possible ways to resolve the descendant elements' style;
1) Traversing unstyled elements in animation-only restyle
We can't simply traverse unstyled elements in the animation-only restyle
since when we decided to traverse the unstyled elements we don't know yet
the elements will be initially styled or are in display:none subtree. It
will result that the new elements are styled in animation-only restyle,
it's undesirable.
2) Creating a SequentialTask and resolve the descendants' style with
ServoStyleSet::StyleNewSubtree()
We can't resolve the descendants' styles with ServoStyleSet::StyleNewSubtree()
in SequentialTask since at the moment we are still in servo traversal (i.e.
sInServoTraversal is true). That means AutoSetInServoTraversal fails
in PrepareAndTraverseSubtree().
3) Creating a SequentialTask and set restyle subtree hint and defer descendants'
restyle in a subsequent normal traversal
Note that, when we process throttled animations flush, we don't process
normal traversal so the descendants will not be traversed until normal
restyle happens but it will not be a big problem since it's really rare
that user clicks display animation element just at the right moment when
display property changes from none to other. Also, if it will be really
a problem, we should process *only* transform animations on the compositor,
it's ideally right thing to do. Display property never runs on the
compositor.
This patch takes the third approach.
MozReview-Commit-ID: Krxa3kkdIq4
--HG--
extra : rebase_source : 33e9db953f21168c76716329568191625bd15896
When a container layer's transform has an animated scale, we clamp it
to a near power of two so that descendent layers' resolutions do not
keep changing and we minimize repainting. The current behaviour only
clamps the scale when it has not changed with respect to the previous
transaction. In animations where the scale usually changes, but
happens to remain constant between two consecutive transactions, this
is bad.
Rather than only checking against the previous scale value, use
ActiveLayerTracker::IsScaleSubjectToAnimation() to determine whether
to clamp, as it takes into account a longer period.
--HG--
extra : rebase_source : 6bc773e387c5750746722d4a0cc5864ebf7757e2
This used to be necessary when larger/smaller did a table lookup.
However as of bug 1361550 these are simple ratios and should be treated
the same as em units.
MozReview-Commit-ID: 2zM7O0awynG
CSSparserImpl::ParserShadowItem stores shadow items in a different order that
does not match the order we use when serializing computed shadow items.
The items order of storing by parser:
<length> <length> <length> <length> <color> <inset>
The items order of serializing:
<color> <length> <length> <length> <length> <inset>
Spec of this serialized order is as follow:
5c46d78107
This patch will shuffle the order of this items in the shadow array when
serializing it.
MozReview-Commit-ID: CIawpYKKIRy
--HG--
extra : rebase_source : 9b4f5d20543980baa45c07c950fa0baa59d9cc93
For an import loop sheet, set the URIs and principal, and mark it complete, so
that it can still be properly accessed via CSSOM without errors.
MozReview-Commit-ID: 1oO1LoaPk8V
--HG--
extra : rebase_source : 2de1e8e03a2e8934710c2f2631f771bc067923d3
Instead of the WebRenderLayerScrollData code knowing about all the
different display item types, it makes more sense to move this logic
into the display items.
In addition to avoiding dis-encapsulating the data from nsDisplayItem subclasses,
this makes it easier to handle two specific scenarios:
(1) the case where an nsDisplayItem A subclasses another nsDisplayItem B, but A
and B have different types returned by GetType(). Previously A and B would have
to be handled explicitly in the WebRenderLayerScrollData switch statements,
which doesn't scale well if new types are added. With the new approach the
virtual function is shared down from A to B and so takes care of it. This is
particularly relevant for types like nsDisplayOwnLayer which have a number of
subclasses.
(2) the case where a display item *might* have APZ-relevant information.
In this case the type of the item alone is not sufficient to determine
if we need to create a new WebRenderLayerScrollData for it. Instead, we
need to access specific state inside the display item. This is now
handled by the UpdateScrollData function returning true when passed
nullptr arguments, and replaces the switch statement in
WebRenderLayerManager that updated forceNewLayerData.
MozReview-Commit-ID: FlfHlgSccSn
--HG--
extra : rebase_source : d1fe841724cc6020433aea31ffb5214d8a44d0a9
This is similar like the previous patch, but for the 8-bit string variants.
Also, it changes assignment to Adopt() in GetCString() and GetDefaultCString()
to avoid an extra copy.
--HG--
extra : rebase_source : eba805c3a7b809d5ccd6e853b1c9010db9477667
nscoord_MAX is (1<<30) so that we can check for overflow *after* adding
two nscoords. However, (nscoord_MAX + nscoord_MAX) will still overflow.
Subtracting one makes this no longer possible.
MozReview-Commit-ID: BtbQRMp5kWm
Add ServoFontFeatureValuesRule for CSSOM representation of
@font-feature-values rule and wire up with bindings.
MozReview-Commit-ID: B4Lpj43bvKX
--HG--
extra : rebase_source : 6508027f88ff76784ed7d0e5420d6e174f116b38
Because we want to remove nsAdoptingString. We have other variants that don't
use nsAdoptingString, which can be used instead. There are three basic
patterns.
1. The easiest case is when we don't check for success.
> nsAdoptingString s = Preferences::GetString("foo");
> foo(s);
becomes:
> nsAutoString s;
> Preferences::GetString("foo", s);
> foo(s);
2. The next case is when we check if the result is empty.
> nsAdoptingString s = Preferences::GetString("foo");
> if (s.IsEmpty()) { ... }
becomes:
> nsAutoString s;
> Preferences::GetString("foo", s);
> if (s.IsEmpty()) { ... }
3. The final case is when we null check the result.
> nsAdoptingString s = Preferences::GetString("foo");
> if (s) { ... }
becomes:
> nsAutoString s;
> nsresult rv = Preferences::GetString("foo", s);
> if (NS_SUCCEEDED(rv)) { ... }
The patch also avoids some UTF8/UTF16 conversions in a few places.
--HG--
extra : rebase_source : f339b1a3dda4dc93979d38c30c001fbe77485b55
Extract CSSFontFeatureValuesRule from nsCSSFontFeatureValuesRule
class. This is necessary because we will create a FontFeatureValues
rule for Servo side.
MozReview-Commit-ID: GKy5wa6JLv9
--HG--
extra : rebase_source : 015f13da9a776c4ece8aa13655395afbb347b870
This bug report became semi-obsolete after we restructured the way flex items
are reordered for the CSS 'order' property. I'm adding its testcase as a
crashtest for good measure & for regression-testing.
MozReview-Commit-ID: 9ytJymbxZx
I believe crashtest 876074-1.html stopped asserting (about flex item frame-list
sortedness) once we stopped reordering the flex item child-list, in bug 812687.
So we don't need this asserts() annotation anymore.
MozReview-Commit-ID: BlMoFnkLQeU
nsMenuPopupFrame will constrain the size of its widget to its min and max size.
It will also request its nsView to resize to its frame rect. If its frame rect
is larger or smaller than the min or max size, nsView will be unable to change
the size of the widget, and each ViewManagerFlush will attempt a resize and
force a composite. When there are a lot of ViewManagerFlushes, this can
overload the compositor.
--HG--
extra : rebase_source : e32c3bb5445365ef76ea2a0700abb6911974afcc
extra : source : cadcf04ef23cee5ddbbbf216573c05d3fc0e53f2
This bug report became semi-obsolete after the assertion it triggered was
removed (as part of CSSUnprefixingService being replaced with native code).
I'm adding its testcase as a crashtest for good measure & for
regression-testing.
MozReview-Commit-ID: GhsoI8UHqI8
This patch replaces four functions of the name AssignWithConversion which
are essentially wrappers around CopyASCIItoUTF16 and LossyCopyUTF16toASCII
with direct calls to the latter two functions. The replaced functions are:
void nsCString::AssignWithConversion( const nsAString& aData )
void nsString::AssignWithConversion( const nsACString& aData )
void nsTString_CharT::AssignWithConversion(
const incompatible_char_type* aData,
int32_t aLength = -1);
The last of the three exists inside the double-included nsTString* world and
so describes two functions, giving four in total.
This has two advantages:
* it removes code
* at the call points, it makes clear (from the replacement name) which
conversion is being carried out. The generic name "AssignWithConversion"
doesn't make that obvious -- one had to infer it from the types.
The patch also removes two commented out lines from
editor/composer/nsComposerCommands.cpp, that appear to be related. They are
at top level, where they would never have compiled. They look like
leftovers from some previous change.
--HG--
extra : rebase_source : fb47bf450771c3c9ee3341dd14520f5da69ec4f5
With this patch, we now have an automated test to verify if a transition
is run properly on a visited link. Note that the test aims to verify
the behavior in Stylo should match that in Gecko. Due to Bug 868975, we
haven't supported transitioning on visited styles yet, so the test should
be put in our own repo for now. This test can be tweaked and put into
web-platform repo once we resolve Bug 868975.
MozReview-Commit-ID: Ci1cERXkIUK
--HG--
extra : rebase_source : 7feb1229bc2dc430bc2a1e40be40047049469fbd
I've been having problems with interdiffs on mozreview lately, so for
ease of review, this patch is being submitted as a seperate patch for
review. Once it is r+'d, it will be folded into the first patch in
this set before landing.
MozReview-Commit-ID: CS9MngaXlBd
--HG--
extra : rebase_source : 6a86fd4f7a66e73497a756976a2562d183002a2a
Removes applet tag interfaces, and changes HTML5 parser to output
HTMLUnknownElement when tag is found. Removes tag process from various
places in the browser.
MozReview-Commit-ID: 2zHhK2U2esX
--HG--
extra : rebase_source : d06ecaffd1cb656301e29b900bafde4c68a4606e
This doesn't actually implement style context reparenting in the style set yet; that part is next.
There is one behavior difference being introduced here compared to Gecko: we
don't reparent the first block piece of an {ib} (block-inside-inline) split
whose first inline piece is being reparented. This is actually a correctness
fix. In this testcase:
<style>
#target { color: green; }
#target::first-line { color: red; }
</style>
<div id="target">
<span>
<div>This should be green</div>
</span>
</div>
Gecko makes the text red, while every other browser makes it green.
We're preserving Gecko's behavior for out-of-flows in first-line so far, but
arguably it's wrong per spec and doesn't match other browsers either. We can
look into changing it later.
MozReview-Commit-ID: 5eC6G449Mlh
--HG--
extra : rebase_source : 8c333a0afe96c68a4e3b6aeca1b742ef8d5edd3b
The style contexts are already correct here; the frame constructor ensures that.
MozReview-Commit-ID: CWO225MB6Pe
--HG--
extra : rebase_source : ebc74ab507aaad6ac4c301cbbcdcab30ad3034d0
We don't need to reparent when moving things in/out of anonymous boxes and using the stylo backend.
MozReview-Commit-ID: 8C6ScqTuR9z
--HG--
extra : rebase_source : 0f180647a39a051e2a5aabe642031134852bf95b
We need this new API in the following patch.
MozReview-Commit-ID: JSoCgzKWrfs
--HG--
extra : rebase_source : e7da0a990b991b1c417015a9cb4f9e2b1e98faae
extra : source : 8f02c1ea8448315f9284939823d66e67cdc5ad87
Since we make "font-variant-alternates" animatable,
should remove test fail annotation from reftest.list.
MozReview-Commit-ID: ChdeSvUbTBh
--HG--
extra : rebase_source : fac9fb01a60c684d7169866964621f431b3508e3
The details element, which is a sibling of an animating element, is checked
whether the element needs to be processed in a post traversal for throttled
animation flush because the parent element has animation-only dirty bit (i.e.
the parent element is a common ancestor of the animating element and the
details element). Also at the moment of the check the details element has
reconstruct frame damage because 'open' attribute is changed. Thus in the check
the details element was not restyled but had reconstruct frame damage.
MozReview-Commit-ID: FvsyZlUjhFi
--HG--
extra : rebase_source : 80ee22e7a3092ee208ce74304c242da782f6a0f4
This allows us to turn on layers-free mode in the firefox UI process,
and have it work better in that the content process' content actually
shows up.
MozReview-Commit-ID: qBnfueYmuf