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
Add debug() for the process handler and process reader classes, and add a few
debug() calls that I am interested in.
Differential Revision: https://phabricator.services.mozilla.com/D23946
--HG--
extra : moz-landing-system : lando
We haven't seen any AMD related bugs on Nightly so I'd like to expand
our scope further.
Differential Revision: https://phabricator.services.mozilla.com/D23944
--HG--
extra : moz-landing-system : lando
The heuristic to scroll the console output to the bottom was
to only look if new messages were visible. But it can happen
that such case is triggered by only opening a closed group.
This patch tweaks the heuristic a bit to exclude the case
where we open a group, while making sure that we still
scroll to bottom if there are new, opened, group messages.
A test is added to ensure this works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D23996
--HG--
extra : moz-landing-system : lando
Added a condition in the `openStatistics` action to check if Disabled Cache is checked, if yes, do a reload with cache disabled
Differential Revision: https://phabricator.services.mozilla.com/D23856
--HG--
extra : moz-landing-system : lando
When changing addr_info we didn't always update addr_info_gencnt, so when it the old AddrInfo was freed, even though we lock in nsDNSRecord::GetNextAddr, mIter would still point to the old AddrInfo.
Differential Revision: https://phabricator.services.mozilla.com/D23923
--HG--
extra : moz-landing-system : lando
