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
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
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
The unit of nsCSSValue is always number/pixel/percent or eCSSUnit_Calc,
so we don't need the style context for Servo backend.
Besides, ReadTransform is a public API used in many places, so we keep
its argument type as nsStyleContext.
MozReview-Commit-ID: KLdrJ5BJXg8
--HG--
extra : rebase_source : 778ca38b06e2a13d3db0465b9e74bd0c33c62a88
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
Before bug 929484, border-radius on row groups, rows, column groups,
or columns don't apply to the background of each cell, yet the
border-radius on the cell itself does. After bug 929484, the behaviors
changed. In this patch, I tried to revert the behaviors of border-radius
on table row groups, rows, column groups, or columns back to
what happened before bug 929484.
MozReview-Commit-ID: 1Xg1qHde3lk
--HG--
extra : rebase_source : ff08f8390ff910fe8c141a75275134f77a1cec3e
We overwrites DrawResult returning from
nsCSSBorderImageRenderer::CreateBorderImageRenderer by the returning value of
DrawBorderImage, which is not right.
MozReview-Commit-ID: 1EeqU5hLyln
--HG--
extra : rebase_source : a78aa841795afa830b66da650a619f46230b10dd
