If we have an animation with multiple transform-like properties, it
seems getOMTAStyle(transform) returns an empty string at 50% on
Android x86_64 opt with e10s, so we cannot pass this test case. We
temporarily disable this test case on this platform.
Differential Revision: https://phabricator.services.mozilla.com/D24103
--HG--
extra : moz-landing-system : lando
If the frame supports it (stacking context + containing block for fixed), and a descendant was
modified, we would have created an override dirty region with just the area of that descendant.
In the case where no descendants are modified, we should use an empty rect, rather than
the area inherited from our parent.
This fixes the case where we forcibly build position:fixed frames (since they might async
scroll differently to the rest of the page), but we only need to build the container item,
not the whole frame subtree within it.
Added a test that shows us building the non-intersecting position:fixed, but not items within it.
Differential Revision: https://phabricator.services.mozilla.com/D23610
--HG--
extra : moz-landing-system : lando
And also don't blow the preferences away unless they actually change. We were
blowing them away whenever the document language changed or what not, that's not
good.
Differential Revision: https://phabricator.services.mozilla.com/D23955
--HG--
extra : moz-landing-system : lando
Most rounded rect clips in real content are (a) axis aligned and
(b) have uniform radii.
When these conditions are met, we can run a fast path for clip
mask generation that uses significantly fewer ALU shader ops.
This is not typically a bottleneck on desktop GPUs, but can have
a large performance impact on mobile GPUs (and perhaps low end
integrated GPUs).
The Mali shader analyzer reports the slow path for the rounded
rect clip shader to be 94 cycles per fragment, while the fast
path is 10 cycles.
Differential Revision: https://phabricator.services.mozilla.com/D23817
--HG--
extra : moz-landing-system : lando
Actually the function will fail on Android since on xpcshell tests we don't
initialize AndroidBridge so that we can't query the corresponding system
settings.
Differential Revision: https://phabricator.services.mozilla.com/D22270
--HG--
extra : moz-landing-system : lando
Actually the function will fail on Android since on xpcshell tests we don't
initialize AndroidBridge so that we can't query the corresponding system
settings.
Differential Revision: https://phabricator.services.mozilla.com/D22270
--HG--
extra : moz-landing-system : lando
Actually the function will fail on Android since on xpcshell tests we don't
initialize AndroidBridge so that we can't query the corresponding system
settings.
Differential Revision: https://phabricator.services.mozilla.com/D22270
--HG--
extra : moz-landing-system : lando
This also adds the missing preference in test_transition_per_property.html.
Depends on D22567
Differential Revision: https://phabricator.services.mozilla.com/D22568
--HG--
extra : moz-landing-system : lando
Now, its time to let individual transform run on the compositor thread.
Depends on D19636
Differential Revision: https://phabricator.services.mozilla.com/D22566
--HG--
extra : moz-landing-system : lando
On the sender side of transactions, we have to convert the individual transforms
to the proper types in layers::Animations, and this includes SetAnimatable and
the definition in LayersMessages.
On the compositor side (i.e. received side of transactions). Basically, we
convert the list of layers::Animation into a list of `PropertyAnimationGroup`,
which is an intermediate value. And then use this list to do interpolation for
each property in `SampleAnimationForEachNode`, which will return a list of
`RefPtr<RawServoAnimationValue>`.
Depends on D23062
Differential Revision: https://phabricator.services.mozilla.com/D22565
--HG--
extra : moz-landing-system : lando
It seems this function uses some FFIs to generate the AnimationValue,
We could move it into AnimationValue class, although what we really need is
RefPtr<ServoAnimationValue>.
Maybe we should use AnimationValue everywhere, instead of the Servo type.
This could be done by other patches.
Differential Revision: https://phabricator.services.mozilla.com/D22562
--HG--
extra : moz-landing-system : lando
And rename the constants to not be prefixed by TOUCH_ACTION_, since that's part
of the type name anyway.
Differential Revision: https://phabricator.services.mozilla.com/D23413
--HG--
extra : moz-landing-system : lando
Most rounded rect clips in real content are (a) axis aligned and
(b) have uniform radii.
When these conditions are met, we can run a fast path for clip
mask generation that uses significantly fewer ALU shader ops.
This is not typically a bottleneck on desktop GPUs, but can have
a large performance impact on mobile GPUs (and perhaps low end
integrated GPUs).
The Mali shader analyzer reports the slow path for the rounded
rect clip shader to be 94 cycles per fragment, while the fast
path is 10 cycles.
Differential Revision: https://phabricator.services.mozilla.com/D23817
--HG--
extra : moz-landing-system : lando
If the frame supports it (stacking context + containing block for fixed), and a descendant was
modified, we would have created an override dirty region with just the area of that descendant.
In the case where no descendants are modified, we should use an empty rect, rather than
the area inherited from our parent.
This fixes the case where we forcibly build position:fixed frames (since they might async
scroll differently to the rest of the page), but we only need to build the container item,
not the whole frame subtree within it.
Added a test that shows us building the non-intersecting position:fixed, but not items within it.
Differential Revision: https://phabricator.services.mozilla.com/D23610
--HG--
extra : moz-landing-system : lando
Currently the MobileViewportManager leaves somethings permanently changed
even after it is destroyed: it may have changed the resolution of
the Document, and it may have set a fixed size for the visual viewport.
Both of these changes need to be un-done to return to normal display of
the Document.
Differential Revision: https://phabricator.services.mozilla.com/D17999
--HG--
extra : source : 088dc24eabc75eea96301d50550e0a8817f5f809
Once nsIPresShell::SetVisualViewportSize is called, we currently have
no way to restore the default viewport sizing behavior. This corrects that.
We need the default behavior to get correctly-placed scrollbars when
turning off meta viewport handling in Responsive Design Mode panes.
Differential Revision: https://phabricator.services.mozilla.com/D20593
--HG--
extra : source : 178210eb72baa05f877b3a35e0c94d0b23880d13
Also update ScrollFrameHelper::LayoutScrollbars() to correctly handle
overlay scrollbars when zoomed in in RDM.
Differential Revision: https://phabricator.services.mozilla.com/D20591
--HG--
extra : source : 6a84e97d0e62839c3028a3c3ac89cd944f8e39e5
It's not very easy to understand on its current state, and it causes subtle bugs
like bug 1533654.
It could be simpler if we centralized where the interactions between properties
are handled. This patch does this.
This patch also changes how MathML script sizes are tracked when scriptlevel
changes and they have relative fonts in between.
With this patch, any explicitly specified font-size is treated the same (being a
scriptlevel boundary), regardless of whether it's either an absolute size, a
relative size, or a wide keyword.
Relative lengths always resolve relative to the constrained size, which allows
us to avoid the double font-size computation, and not give up on sanity with
keyword font-sizes.
I think given no other browser supports scriptlevel it seems like the right
trade-off.
Differential Revision: https://phabricator.services.mozilla.com/D23070
--HG--
extra : moz-landing-system : lando
Emilio Cobos Álvarez
Andreea Pavel
Boris Chiou
Matt Woodrow
Glenn Watson
Henri Sivonen
Jonathan Kew
Hiroyuki Ikezoe
Coroiu Cristina
Cameron McCormack
Bogdan Tara
Botond Ballo
Brad Werth
shindli