This makes the macOS native compositor claim the ability to handle color
layers and makes NativeLayerCA actually do it. Color layers have a different
structure than other layers. Color layers apply the color to the
wrappingCALayer, and have no contentCALayer at all. That means that the
color layers are always sized to the layer's clip rect.
This also contains a drive-by fix to handle the case where an mOpaquenessTintLayer
exists when mMutatedSpecializeVideo is set to true. Before this change, in such a
case, the opaqueness layer will not be associated with the recreated wrapping layer.
Differential Revision: https://phabricator.services.mozilla.com/D128545
WebRenderErrors errors after initialization will often be memory/driver
related. We can try to recover from this more gracefully by tearing down
the compositors instead of just crashing when we have finished falling
back. If one has a GPU process, it will be killed, and otherwise, it
will simulate a device reset in the parent process. This graceful
recovery can only be used if the process is declared "stable", according
to existing criteria for the GPU process (minimum uptime and frames
composited).
Differential Revision: https://phabricator.services.mozilla.com/D146477
With CI's NVIDIA GPU, SharedHandle of ID3D11Texture2D of hardware decoded video during no video copy caused rendering problem. When SharedHandle is not used, the rendering problem did not happen. But when video is rendered to WebGL texture, SharedHandle need to be used.
In this case, D3D11TextureIMFSampleImage copies original ID3D11Texture2D to a new ID3D11Texture2D and use a shared handled of the copied texture. And no video copy of future video frames are disabled.
NoCopyNV12Texture is renamed to ZeroCopyNV12Texture to clarify its meaning.
Differential Revision: https://phabricator.services.mozilla.com/D144598
There is a case that mSize and size of mTexture are different. In this case, size of SourceSurface becomes different from mSize.
Differential Revision: https://phabricator.services.mozilla.com/D146279
Implement dominant axis scrolling on mac by using the default axis
locking mode (sticky), setting the locking angle to 45 degrees, and
setting the breakout angle to 45 degrees.
Depends on D146609
Differential Revision: https://phabricator.services.mozilla.com/D146610
When in STICKY axis locking mode and the axis lock is broken, lock onto
the opposite axis, if the input angle is within the breakout_angle from
the opposite axis.
Depends on D144854
Differential Revision: https://phabricator.services.mozilla.com/D146609
When in the STANDARD or STICKY axis locking mode, ensure that axis locks
are held through the state transition from panning on the x or y axis
into the momentum scroll. This change only implements this form of
momentum scroll axis locking when the momentum scroll occurs due to a
momentum pan gesture, which currently only occurs on mac.
Differential Revision: https://phabricator.services.mozilla.com/D144854
Although not needed right now (checkerboarding backgrounds get
a slice anyway due to being a different scroll root), this will
be important for the upcoming work to make backdrop filter
roots implicit. This allows WR to know when slicing up a content
slice if the prim is relevant to the backdrop root.
Differential Revision: https://phabricator.services.mozilla.com/D146145
We need transfer aligned surface size, VA-API add extra width/height to decoded surface to keep 16px alignment
and some GL drivers (like AMD) refuses to create EGLImage when stride and width does not match (Bug 1724385).
Differential Revision: https://phabricator.services.mozilla.com/D146084
- Update the APZ scroll linked effect mochitest to await for
synthesizeNativeWheel.
- Call synthesizeNativeWheel in a setTimeout callback to ensure the
eventTimeStamp is an interval.
Differential Revision: https://phabricator.services.mozilla.com/D145878
bug 1733732 decreased the size of the display port on Android. When you scroll to the bottom of the page, the canvas leaves the display port. It triggers to destroy WebRenderCanvasData and WebRenderCanvasRendererAsync. And then RenderAndroidSurfaceTextureHost::NotifyNotUsed() is called and RenderAndroidSurfaceTextureHost is destroyed.
Then if scrolling makes the canvas into the display port again, WebRenderCanvasData, WebRenderCanvasRendererAsync and RenderAndroidSurfaceTextureHost are recreated again. But there is no rendering update at SharedSurface_SurfaceTexture. Since the page does WebGL rendering only once during page load.
It caused the problem to RenderAndroidSurfaceTextureHost. RenderAndroidSurfaceTextureHost::NotifyNotUsed() returns SurfaceTexture's buffer to client side. For using SurfaceTexture again in RenderAndroidSurfaceTextureHost, Client side needs to do re-rendering to SurfaceTexture. But SharedSurface_SurfaceTexture did nothing in this case.
To address the problem, we could hold layers::CanvasRenderer in ClientWebGLContext::mNotLost. If WebRenderCanvasRendererAsync is kept alive, RenderAndroidSurfaceTextureHost::NotifyNotUsed() and destruction of WebRenderCanvasRendererAsync do not happen.
Then if WebRenderCanvasData is re-created, the stored WebRenderCanvasRendererAsync is set in the new WebRenderCanvasData in ClientWebGLContext::UpdateWebRenderCanvasData().
Differential Revision: https://phabricator.services.mozilla.com/D143811
The bulk of the changes are to make the sending of events much more similar to how widget/tests/browser/browser_test_swipe_gesture.js works (because that is a test that is currently working well).
browser_test_swipe_gesture.js opens a tab and uses tab.linkedBrowser to target the events. This makes sense because when we add the event listeners here https://searchfox.org/mozilla-central/rev/b72e9d7d63bf499d1d8168291b93d4ec7fde236e/browser/base/content/browser-gestureSupport.js#49 we add them to the tabbox.
We create synthesizeSimpleGestureEvent in apz_test_native_event_utils.js so we can target other elements (rather than widget relative coords) more easily. This makes several functions async so we propagate that through.
We also change the coords from 0,0 to 10,10 to make sure it's within the bounds of the tabbox event listener (not sure if this is necessary or not, I didn't test without this).
And then I ran eslint on the file. That's should cover everything, hopefully that explanation makes review relatively easy.
Differential Revision: https://phabricator.services.mozilla.com/D146160
The scroll snap spec defines the concepts [1]. There are three type of scroll
operations. 1) intended end position, 2) intended direction and end position
and 3) intended direction.
Basically our existing ScrollUnits types correspond;
1) DEVICE_PIXELS, WHOLE => intended end position
2) PAGES => intended direction and end position
3) LINES => intended direction
There are two exceptions in the `intended direction and end position` case,
scrollBy() and fling gestures (on Linux). They were defined as scroll operations
with DEVICE_PIXELS unit, but the spec cleary says they are `intended direction
and end position` operations.
Note that we will also use this information for scroll-snap-stop property since
the properly will only have effects on both 2) and 3) cases.
[1] https://drafts.csswg.org/css-scroll-snap/#scroll-types
Depends on D145190
Differential Revision: https://phabricator.services.mozilla.com/D145191
The scroll snap spec defines the concepts [1]. There are three type of scroll
operations. 1) intended end position, 2) intended direction and end position
and 3) intended direction.
Basically our existing ScrollUnits types correspond;
1) DEVICE_PIXELS, WHOLE => intended end position
2) PAGES => intended direction and end position
3) LINES => intended direction
There are two exceptions in the `intended direction and end position` case,
scrollBy() and fling gestures (on Linux). They were defined as scroll operations
with DEVICE_PIXELS unit, but the spec cleary says they are `intended direction
and end position` operations.
Note that we will also use this information for scroll-snap-stop property since
the properly will only have effects on both 2) and 3) cases.
[1] https://drafts.csswg.org/css-scroll-snap/#scroll-types
Depends on D145190
Differential Revision: https://phabricator.services.mozilla.com/D145191
Since we're going to be keeping around empty cache pages, which can further
increase memory pressure, it would be nice if we respond to memory pressure
events by evicting the empty cache pages.
Differential Revision: https://phabricator.services.mozilla.com/D145499
This additionally changes acceptProvidedSublayers to a C++ lambda function,
which keeps the compiler happy with iterating over the new nsTArray.
Differential Revision: https://phabricator.services.mozilla.com/D143220
Before this patch the hit test info is accumulated in the painting loop of a group, there are two issues with that:
- We can early out before getting to the painting loop if the group does not contain any visible item (hit test info items don't count as visible) so a nsDisplayCompositorHitTestInfo can be ignored if it is between two active items.
- Group boundaries should not affect the behavior of hit testing.
With this patch, hit test info is accumulated in the ConstructItem loops, is not reset in EndGroup and is carried over from a group to the next.
This means the hit test flags are extended to the scope of the svg container, I'm not entirely sure that it's correct but I believe it is at least less incorrect than the current behavior.
Differential Revision: https://phabricator.services.mozilla.com/D145358
... if the group had hit test flags set.
This is more of a workaround than a proper fix. The general idea is that if we hadn't made the item active, its bound would have included in the group's hit tested bounds. Making the item active reduces the area that is covered by hit test items and we don't want that.
***
fixup
Differential Revision: https://phabricator.services.mozilla.com/D143755
This additionally changes acceptProvidedSublayers to a C++ lambda function,
which keeps the compiler happy with iterating over the new nsTArray.
Differential Revision: https://phabricator.services.mozilla.com/D143220
Our scrollbar drawing code had various RTL checks for the writing mode.
These checks were busted since bug 1554571 (where the writing-mode of
the scrollbar frames and so on is reset). However, they also wouldn't be
correct (we allow to customize scrollbar position via pref).
Instead, look at the scrollable frame to really know if the scrollbar is
on the right or not. Compute that once in Theme.cpp and pass it around
light we were doing for the "is horizontal" bit.
Differential Revision: https://phabricator.services.mozilla.com/D145865
IsZero() is changed to take a CSSPoint parameter instead of any
point type, to avoid accidentally re-introducing the issue.
Differential Revision: https://phabricator.services.mozilla.com/D145173
Make the APZ mochitests use coor coordinatesRelativeToScreen and its callers
properly. When was made async not everything was made to await properly.
Differential Revision: https://phabricator.services.mozilla.com/D144756
Crashes of Bug 1764753 seemed to happen during closing video MFTDecoder or closing IMFSample after closing video MFTDecoder. We might need to release all IMFSamples before destroying video MFTDecoder.
Differential Revision: https://phabricator.services.mozilla.com/D144537
IsZero() is changed to take a CSSPoint parameter instead of any
point type, to avoid accidentally re-introducing the issue.
Differential Revision: https://phabricator.services.mozilla.com/D145173
IsZero() is changed to take a CSSPoint parameter instead of any
point type, to avoid accidentally re-introducing the issue.
Differential Revision: https://phabricator.services.mozilla.com/D145173
Make the APZ mochitests use coor coordinatesRelativeToScreen and its callers
properly. When was made async not everything was made to await properly.
Differential Revision: https://phabricator.services.mozilla.com/D144756