This is part of the effort to get all the other versions of rand out.
Unfortunately the diff is kinda bug because this is the first crate
requiring rand 0.6 which has been split into multiple crates.
Differential Revision: https://phabricator.services.mozilla.com/D30744
--HG--
extra : moz-landing-system : lando
Profiling shows that we're spending a lot of time on startup inside
android.media.MediaCodecList.getCodecCount when GfxInfo::GetFeatureStatus calls
over to Java to determine whether hardware accelerated video encoding is
supported.
Looking at the Java stacks in the profile, Android is spending most of our time
creating a list of codecs. It doesn't look like there's a faster way to query
for hardware accelerated video support. So to speed this up we can cache the
value in the user's profile. We also store the OS version, which we can use to
detect when the OS is updated so we can invalidate the cache then.
Presumably an OS update is the only way a device can have its hardware acceleration
support status change.
With this change, the time we take figuring out the HW encode/decode status
goes from ~100ms on a cold run to ~0.01ms on a cache hit on my HD8 tablet.
Differential Revision: https://phabricator.services.mozilla.com/D31380
--HG--
extra : moz-landing-system : lando
Use more compact types, and remove some manual implementations that can be
derived.
Differential Revision: https://phabricator.services.mozilla.com/D31315
--HG--
extra : moz-landing-system : lando
This avoids the expensive conversion, and cleans up a bunch.
Further cleanup is possible, just not done yet to avoid growing the patch even
more.
Differential Revision: https://phabricator.services.mozilla.com/D30748
--HG--
extra : moz-landing-system : lando
We need this to auto-generate the copy-constructor for TransformOperation,
without which the patch wouldn't build.
Differential Revision: https://phabricator.services.mozilla.com/D30799
--HG--
extra : moz-landing-system : lando
We could use ArcSlice if wanted I guess, your call. Though will change is not
supposed to be used very frequently.
Differential Revision: https://phabricator.services.mozilla.com/D30548
--HG--
extra : moz-landing-system : lando
This adds a bit of complexity, which I think will pay off in the end. Removals
incoming.
Differential Revision: https://phabricator.services.mozilla.com/D30544
--HG--
extra : moz-landing-system : lando
This is just a refactor in the right direction. Eventual goal is:
* All inherited properties use ArcSlice<>.
* All reset properties use OwnedSlice<> (or ThinVec<>).
No conversion happens at all, so we can remove all that glue, and also
compute_iter and co.
Of course there's work to do, but this is a step towards that.
Differential Revision: https://phabricator.services.mozilla.com/D30127
--HG--
extra : moz-landing-system : lando
This makes DrawTarget and ReadTarget no longer require a borrow
on a texture. This was previously fine, but in the near future
WR will be rendering picture caching surfaces directly into
texture handles. To allow this, we need to remove the borrow check
requirement on DrawTarget for rustc.
Differential Revision: https://phabricator.services.mozilla.com/D31390
--HG--
extra : moz-landing-system : lando
Display these when available instead of generating one.
We play some games here to let SinglePreferenceExperiment continue to
validate according to the PreferenceExperiment schema. This is kind of
ugly. Another approach might be to move the about-studies code that
generates a description. I was hesitant to do this because it would
mean losing the formatting.
Depends on D29873
Differential Revision: https://phabricator.services.mozilla.com/D30969
--HG--
extra : moz-landing-system : lando
The existing, single-preference action format is supported by a new
SinglePreferenceExperimentAction, which converts single-preference
actions into multiple-preference actions. We keep the wire format name
"preference-experiment" for SinglePreferenceExperimentAction for now,
but perhaps one day we can move that to "single-preference-experiment".
Depends on D29872
Differential Revision: https://phabricator.services.mozilla.com/D29873
--HG--
extra : moz-landing-system : lando
Add a little bit to some existing tests to cover this new
functionality.
Depends on D29871
Differential Revision: https://phabricator.services.mozilla.com/D29872
--HG--
extra : moz-landing-system : lando
Move startObserver to take a preferences object and register its
observer for each preference in that object.
While we're here, move to the canonical observer interface according
to nsIPrefBranch.idl, with an `observe` method instead of just passing
a function.
Also perform some drive-by cleanups in the tests: add a name to one
test, drop some unused arguments to some other tests.
Depends on D29293
Differential Revision: https://phabricator.services.mozilla.com/D29871
--HG--
extra : moz-landing-system : lando
This is part 1 of the required changes. This just addresses the
storage mechanism and any place that uses experiments in their raw
form. This updates most callers to support studies with multiple
preferences.
We update about-studies to assume only one preference. This seems
counterproductive, but studies with multiple preferences will include
a description field that obviates the need for this.
Differential Revision: https://phabricator.services.mozilla.com/D29293
--HG--
extra : moz-landing-system : lando
I wasn't sure what we should show in the case of unofficial builds. Curently the logo is just hidden for those builds.
Differential Revision: https://phabricator.services.mozilla.com/D31286
--HG--
extra : moz-landing-system : lando
There have been several people that thought app update was broken because this message was reported as an error so just use logStringMessage
Differential Revision: https://phabricator.services.mozilla.com/D31524
--HG--
extra : moz-landing-system : lando
The mozilla::java::WebAuthnTokenManager asserts its return-to-C++ callbacks as
being run on the main Android UI thread, but since these methods are called
directly from the Fido2PendingIntent listeners, there's no guarantee of that.
We don't actually care what thread was tasked with returning us data, just that
it gets done, so let's not assert the thread here.
Differential Revision: https://phabricator.services.mozilla.com/D31497
--HG--
extra : moz-landing-system : lando
