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
Re-enabling the PGO jarlog, which was unexpectedly disabled since Firefox 56
showed a regression on Windows 7, due to the use of mozilla::ReadAhead,
which on Windows 7 does explicit I/O on the caller thread.
While there may be some benefit from doing so, evidence says the
opposite, which is presumably due to the amount of data being loaded not
being relevant in every case: the jarlog is gathered from a first-run,
which has a different jar-loading profile from subsequent runs of
Firefox.
While we may want to improve the situation later on, the immediate thing
we can do is stop doing this explicit read, while keeping the OS
readahead hints on other platforms, which don't imply explicit I/O.
All this does is effectively get us back to the same state as if jarlogs
were disabled like it was since Firefox 56, for Windows 7 only.
aFd not being used anymore, the code could be cleaned up a lot, but we
may reintroduce the readahead later, so keep the status quo for now.
Differential Revision: https://phabricator.services.mozilla.com/D23642
--HG--
extra : moz-landing-system : lando
comm-task-env runs before run-task and updates the environment with GECKO_*
variables that are defined in a file at the root of a subproject's repository,
such as "comm-central".
Updates:
- add comm-task-env
- add python 3.5 (run-task dependency)
- add pyyaml
Differential Revision: https://phabricator.services.mozilla.com/D16934
--HG--
extra : moz-landing-system : lando
comm-task-env runs before run-task and updates the environment with GECKO_*
variables that are defined in a file at the root of the comm repository,
".gecko_rev.yml". run-task needs these variables to be set to find the
correct mozilla repository to check out for a particular TB build.
The current pinning method of updating ".taskcluster.yml" with the mozilla
repository and revision to pin tois no longer supported.
Differential Revision: https://phabricator.services.mozilla.com/D16783
--HG--
extra : moz-landing-system : lando
We should also throttle other transform-like animations which can run on
the compositor thread, on visibility hidden element without 0% or 100%
keyframe.
Depends on D22568
Differential Revision: https://phabricator.services.mozilla.com/D19634
--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
Drop the hack which prevents individual transform running on the
compositor thread.
Depends on D22566
Differential Revision: https://phabricator.services.mozilla.com/D22567
--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
This function was added for B2G actually, to check if the layer has OMTA for
painting high-res layer. However, It's worth to let it also check other
OMTA transform-like properties.
Depends on D22565
Differential Revision: https://phabricator.services.mozilla.com/D19636
--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
The original implementation about "setting animations" is a little bit hard
to read. In `SetAnimations()`, we create a new intermediate data,
`AnimData`, and we mutate the original animations. And then iterate this
mutated animations & intermediate data for sampling. In this bug, we are
planning to group the AnimData as a useful data structure for supporting
multiple properties transform-like animations, so it seems the structure
of original animations may be hard to use after that. Therefore,
we decide to do some reworks on this:
First, we do renames,
1. InfalliableTArray to nsTArray. (They are the same.)
2. AnimData to PropertyAnimation.
3. SetAnimations() to ExtractAnimations(), which returns
nsTArray<PropertyAnimationGroup>. Each entry in the array is for one
property. In this patch, there is only one entry. We will extend this
to multiple entries in the next patch.
And then rework `ExtractAnimations()`, which stores all the necessary data
in `PropertyAnimationGroup`. For WR, we store this in
`CompositorAnimationStorage`. For non-WR, we store it in `AnimationInfo`.
So we can just use this organized data structure for supporting multiple
properties animations. (See the next patch.)
Depends on D22563
Differential Revision: https://phabricator.services.mozilla.com/D23062
--HG--
extra : moz-landing-system : lando
Both layers and web-render use this function, so we factor it out.
Depends on D22562
Differential Revision: https://phabricator.services.mozilla.com/D22563
--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
This eliminates the need to additionally modify gfx.logging.level on
non-debug builds to make apz.printtree output show up.
Differential Revision: https://phabricator.services.mozilla.com/D23880
--HG--
extra : moz-landing-system : lando
There are severals wpt tests with high intermittent fail rate, and the reason is that there are some pixels with really small color difference. eg (255,255,255) v.s. (255,254,254).
As we're lacking of `fuzzy` feature on wpt now (which will be implemented in bug1478472), we have no way to avoid these affordable differences.
Therefore, I'm going to disable those tests until we've `fuzzy` on wpt, and will re-enable them afterward.
Differential Revision: https://phabricator.services.mozilla.com/D23984
--HG--
extra : moz-landing-system : lando
Disabled audio-related tests that have caused issues in the past:
- test_audioNotification.html
- test_audioNotificationSilent_audioFile.html
- test_audioNotificationSilent_webAudio.html
- test_audioNotificationStream.html
- test_audioNotificationStopOnNavigation.html
- test_audioNotificationWithEarlyPlay.html
Changes submitted as separate diff as per comments in https://phabricator.services.mozilla.com/D23744?id=76735#inline-137653
Differential Revision: https://phabricator.services.mozilla.com/D23750
--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
Thomas Wisniewski
Hiroyuki Ikezoe
sotaro
Mike Hommey
Rob Lemley
Edwin Gao
Steve Fink
Alexander Surkov
Boris Chiou
Jonathan Kew
Bogdan Tara
Dimi Lee
Alexis Beingessner
Cameron McCormack
Dana Keeler
Daniel Holbert
Mike Conley
Kartikaya Gupta
Alastor Wu
Gabriele Svelto
meandave
Botond Ballo
Emilio Cobos Álvarez
Edouard Oger