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
This adds worker-type alias that has dedicated workers at level-3 for running
instrumented builds, but uses a test worker type at other levels.
Differential Revision: https://phabricator.services.mozilla.com/D23576
--HG--
extra : moz-landing-system : lando
There are a number of ways we want to vary workers over time and jobs, including
- we are working on migrating to gce
- pgo builds have a dedicated worker-type for running the instrumented build
at level 3 but not level 1
Rather than have all tasks know about how the machines are provisioned, this
moves to using short-names for the worker types, and then has a config mapping
those to the actual worker types.
This adds support for aliases, and an initial set of them. Follow up work will
switch the existing uses of these worker types to using the aliases.
Differential Revision: https://phabricator.services.mozilla.com/D22549
--HG--
extra : moz-landing-system : lando
Disable the following tests, with 1536211 serving as the tracking bug:
- test_header_Server_Timing.js (1530871)
- test_trr.js (1532395)
- test_esni_dns_fetch.js (1530752)
Differential Revision: https://phabricator.services.mozilla.com/D23922
--HG--
extra : moz-landing-system : lando
Disable tests as they fail constantly on xpcshell-8 on windows10-aarch64.
Bug 1536221 is filed for investigating why the crashreporter tests still fail.
Differential Revision: https://phabricator.services.mozilla.com/D23940
--HG--
extra : moz-landing-system : lando
In the mochitest harness, is_fennec is populated by examining harness options, and
is_emulator and android_version are populated by examining the device via mozdevice.
The per-test code doesn't have those options and the emulator may not be available
yet, so I've opted for populated those fields from mozharness configuration. In
practice, we only run Android TV on Android 4.3, where is_fennec=True, is_emulator=True,
and android_version=18. I'd like to run TV on Android 7.0/geckoview eventually,
where is_fennec=False, is_emulator=True, and android_version=24.
Since I was here, I also removed 'stylo' from the per-test mozinfo, since that field
is obsolete now.
Differential Revision: https://phabricator.services.mozilla.com/D23595
--HG--
extra : moz-landing-system : lando
This patch also base64-decodes the API inputs before storing in the DB in
anticipation of being able to pass binary data directly (bug 1535752).
Differential Revision: https://phabricator.services.mozilla.com/D23430
--HG--
extra : moz-landing-system : lando
This limits us to 1 preloaded browser per window, in the top 3 normal windows + top 3 private windows.
If we try to create additional browsers beyond that, we instead move a pre-existing browser across.
Differential Revision: https://phabricator.services.mozilla.com/D21129
--HG--
extra : moz-landing-system : lando
The upcoming WebXR API (Bug 1419190) requires intermediate calculations of real-world space coordinates to have more precision with larger ranges. I expect that double precision matrix and quaternions will also be useful in other graphics and layout work.
It would not be ideal to expand the existing classes to always use double precision, as it would incur a significant performance penalty on certain platforms (eg, Arm). The double-precision variants should be used only when required.
The existing gfx::Matrix4x4 and gfx::Quaternion implementation can be extended with templates to generate both single and double precision variants.
Differential Revision: https://phabricator.services.mozilla.com/D22010
--HG--
extra : moz-landing-system : lando
- Modify ProcessDecodedData to return a MediaResult.
- RemoteDecoderParent::RecvInput and RemoteDecoderParent::RecvDrain
both use error returned from ProcessDecodedData to call SendError.
- RemoteVideoDecoderParent and RemoteAudioDecoderParent both return
MediaResult with NS_ERROR_OUT_OF_MEMORY if AllocShmem fails in
ProcessDecodedData (or if the returned buffer size is less than
the requested size).
Differential Revision: https://phabricator.services.mozilla.com/D23988
--HG--
extra : moz-landing-system : lando
This uses the Endian routines to ensure that reads will match the endianess
of the current machine, which is the expected behaviour of the openh264
plugin. The calls to readUint16 and readUint32 memcpy to a properly aligned
buffer avoiding any problems with alignment. The memcpy adds some overhead
but it seems negligible compared to the amount of work done to packetize and
send the encoded data.
These changes were tested by adding code to create an unaligned buffer and
memcopying the received buffer into it.
This also adds a null check for the received buffer as we have seen a small
volume of null pointer crashes.
Differential Revision: https://phabricator.services.mozilla.com/D24030
--HG--
extra : moz-landing-system : lando
The default color dictionary is implemented,to avoid hardcode color information. The functionality for overridding the values in formatter, is hitherto partially
implemented
Differential Revision: https://phabricator.services.mozilla.com/D23134
--HG--
extra : moz-landing-system : lando
The Flexbox Inspector uses platform APIs that don't take zoom into account whilst the Grid Inspector uses APIs that do take zoom into account.
This means that the zoom calculations when repositioning the canvas need to be different when called from the Flexbox Inspector than when called from the grid inspector.
I have added a `zoomWindow` option to `canvas.js::updateCanvasElement()` that allows us to optionally apply zoom to the current canvas position and the flexbox issue reported in the bug now works just fine.
All the usual other test cases work just fine with this patch applied.
Differential Revision: https://phabricator.services.mozilla.com/D23887
--HG--
extra : moz-landing-system : lando
