As we do not have an IMF nor D3D11 NV12 image, we always require a full copy of the data that will deinterleave the chroma channels.
Depends on D7316
Differential Revision: https://phabricator.services.mozilla.com/D7318
This allows more easily the creation of the MFT required to convert to a RGBA32 image when doing a readback.
Depends on D7295
Differential Revision: https://phabricator.services.mozilla.com/D7296
When decoding a vp9 profile 2 (10 bits), the MF_E_TRANSFORM_STREAM_CHANGE message is returned. We need to look for alternative format type other than NV12: 10/16 bits.
When using those formats, we can no longer assume that the D3D11ShareHandleImage can use NV12. So we will convert to RGBA32 on the fly via a MFT.
Differential Revision: https://phabricator.services.mozilla.com/D7294
As we do not have an IMF nor D3D11 NV12 image, we always require a full copy of the data that will deinterleave the chroma channels.
Depends on D7316
Differential Revision: https://phabricator.services.mozilla.com/D7318
This allows more easily the creation of the MFT required to convert to a RGBA32 image when doing a readback.
Depends on D7295
Differential Revision: https://phabricator.services.mozilla.com/D7296
When decoding a vp9 profile 2 (10 bits), the MF_E_TRANSFORM_STREAM_CHANGE message is returned. We need to look for alternative format type other than NV12: 10/16 bits.
When using those formats, we can no longer assume that the D3D11ShareHandleImage can use NV12. So we will convert to RGBA32 on the fly via a MFT.
Differential Revision: https://phabricator.services.mozilla.com/D7294
To avoid trimming pixels at the top / left.
This makes it closer to non-WR[1], and fixes both the checkboxes getting
cut off and the master password field.
[1]: non-WR at least at 124 scaling on a hiDPI display is still perfect, though I saw nin symmetric borders at other resolutions, so we might be able to improve here further.
Differential Revision: https://phabricator.services.mozilla.com/D7251
--HG--
extra : moz-landing-system : lando
This allows the Axis constructors to use the platform-specific state.
MozReview-Commit-ID: KWtDX4XVpjF
Depends on D7656
Differential Revision: https://phabricator.services.mozilla.com/D7657
--HG--
extra : moz-landing-system : lando
The current velocity computation code is factored out into an implementation
called SimpleVelocityTracker.
MozReview-Commit-ID: G0VnvREdIX3
Depends on D7655
Differential Revision: https://phabricator.services.mozilla.com/D7656
--HG--
extra : moz-landing-system : lando
The motivation is to support velocity tracking implementations (added in a
later patch) that need the position delta rather than resulting velocity.
Also rename the functions to make it clearer that they have to do with
dynamic toolbar movement.
MozReview-Commit-ID: G0IVJHYTurB
Depends on D7654
Differential Revision: https://phabricator.services.mozilla.com/D7655
--HG--
extra : moz-landing-system : lando
When a compositor animation finishes that doesn't apply a fill, rather than
jumping back to the underlying value immediately we should apply a fill mode
until the main thread has a chance to remove the animation from the compositor.
This ensures that any main thread effects that are intended to synchronize with
the end of the animation have a chance to run before we show the underlying
style and helps to avoid flicker in such cases.
Currently we apply this synthesized fill mode to animations when they run
forwards (i.e. positive playback rate), but not backwards. This patch makes us
apply the same handling when running in reverse.
Differential Revision: https://phabricator.services.mozilla.com/D7259
--HG--
extra : moz-landing-system : lando
Previously we would wait at least one transaction from the time the
composition bounds (visual viewport) was updated, but this causes problems
due to the visual and layout viewport being out of sync after a screen
resize, such as one due to dynamic toolbar transitions in Fennec.
Differential Revision: https://phabricator.services.mozilla.com/D7368
--HG--
extra : moz-landing-system : lando
We are refactoring much of the code in gfx/vr, moving
most of the code that runs in the VRListenerThread into
it's own process. The remaining code will be non-blocking
once this refactoring is complete.
In order to resolve some shutdown crashes, it is simpler
to remove the VRListenerThread and the related code
starting and stopping this thread. If this is done
prior to completion of the refactoring for Bug 1473399
(Enable VRService thread by default), there would be a
regression in responsiveness during detection of VR
hardware due to blocking API calls moving off the thread.
Differential Revision: https://phabricator.services.mozilla.com/D7227
--HG--
extra : moz-landing-system : lando
Not sure when this started happening but mRootNode can be null sometimes
during startup so guard against that when turning on APZCTM logging
instead of crashing.
Jean-Yves Avenard
Jeff Muizelaar
Narcis Beleuzu
shindli
Emilio Cobos Álvarez
Ciure Andrei
Botond Ballo
Cosmin Sabou
sotaro
Brian Birtles
Markus Stange
Daniel Varga
Kearwood Gilbert
Tiberius Oros
Kartikaya Gupta