Both DMABUFSurfaceImage and DMABufSurface use its own headless GL context to create GL texture from DMABufSurface.
Let's unity that in DMABufSurface and use only one shared GL context for it.
Depends on D146989
Differential Revision: https://phabricator.services.mozilla.com/D146990
Depends on [`wgpu#2673`].
WebGPU requires `GPUBufferDescriptor` validation failure to:
1) generate an error on the Device timeline, and
2) mark the new buffer as invalid.
Satisfy 1) by moving most validation to the compositor process.
Requirement 2) is harder. `wgpu_core::Global::device_create_buffer`
already takes care of some validation for us, and marks the provided
buffer id invalid when there's a problem. However, there are certain
errors the spec requires us to detect which `device_create_buffer`
cannot even see, because they are caught by standard Rust validation
steps in the process of creating the `wgpu_types::BufferDescriptor`
that one would *pass to* that function. For example, if there are
bogus bits set in the `usage` property, we can't even construct a Rust
`BufferUsages` value from that to include in the `BufferDescriptor`
that we must pass to `device_create_buffer`.
This means that we need to do some validation ourselves, in the
process of constructing that `BufferDescriptor`, and use the
`Global::create_buffer_error` method added in [`wgpu#2673`] to mark
the new buffer as invalid.
[`wgpu#2673`]: https://github.com/gfx-rs/wgpu/pull/2673
Differential Revision: https://phabricator.services.mozilla.com/D146768
Document various things. Spell out that the error messages are UTF-8.
Let `server.rs`'s `ErrorBuffer` take a `&str` instead of a `String`.
Differential Revision: https://phabricator.services.mozilla.com/D146767
There's no need to lazily create a renderer here. We already avoided
this in content processes, but there's no need to do so in the parent
process either.
This shouldn't change behavior, but might help with bug 1772691, and
generally seems cleaner.
Differential Revision: https://phabricator.services.mozilla.com/D148337
When transforming the hit test to what gecko expects, ensure that we
handle fixed elements correctly.
Depends on D146825
Differential Revision: https://phabricator.services.mozilla.com/D148076
Division by zero (and also close to zero values) can cause the interpolant step to
become infinite which can feed bogus values into the shader. Since the left and
right edges in this case are essentially at the same position, we can freely just
choose interpolants from either the left or right edge. Just set the step scale
to zero in this case so we default to the interpolant values from the left edge
and don't step them at all in this case.
Differential Revision: https://phabricator.services.mozilla.com/D148232
Add support for the oculus-touch-v3 (Quest2) input profile. As specified
in the XR input profile we're setting oculus-touch-v2, oculus-touch, and
generic-trigger-squeeze-thumbstick as fallback profiles.
Update the externalVR VRControllerType enum as well.
Co-authored-by: Imanol Fernandez <ifernandez@igalia.com>
Differential Revision: https://phabricator.services.mozilla.com/D147519
layers.
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.
Depends on D128131
Differential Revision: https://phabricator.services.mozilla.com/D128545
This calculates the visible area of the TileCache, and compares against that area
for four purposes:
1) Backdrops must cover only the visible area, not the tile coverage area.
2) Primitives only obstruct the backdrop if they appear in the visible area.
3) Backdrop candidates opaque rects are clipped to the visible area.
4) Subpixel AA is allowed as long as the backdrop rect covers the visible
tiling area, not necessarily the entire tiling area.
All these changes ensure that if a tile coverage area is larger than the window,
backdrops are only considered and created for the visible area.
Note that this has no effect on the contents of tiles that intersect the
backdrop area, wholly or partly. Those tiles, per earlier parts of this
patch, are only set with is_visible=false, which means that they are not
sent to the compositor this frame. The tile surfaces still exist, etc.
This is all in alignment with the idea that we want the entire slice area
(covered by the tiles) to be ready to be scrolled in.
Differential Revision: https://phabricator.services.mozilla.com/D147566
In addition to creating the backdrop surface when it is detected, this also
turns off the rendering of tiles in that same slice. Virtual tiles
associated with compositor surfaces (external or not) will still be
rendered.
This adds a clip check to avoid pushing tiles that are fully clipped out. It
also adds a similar check for compositor surfaces.
Depends on D127175
Differential Revision: https://phabricator.services.mozilla.com/D128131
This only allows native compositors to claim this capability, without changing
any compositors to do so. In Part 4, the macOS native compositor claims this
capability in conjunction with adding the code that handles the color layers.
Differential Revision: https://phabricator.services.mozilla.com/D127175
This creates a helper function in a new class gfxMacUtils that makes the
software and hardware decoders use the same logic. The new class was
necessary because gfxUtils is included in many files that don't include
CoreFoundation headers and would hit namespace collision if it was included
there.
Differential Revision: https://phabricator.services.mozilla.com/D146735
BT709 transfer characteristics may be specified in videos even if they don't
use the BT709 colorSpace. This change also makes BT709 the default, since it
is the safest option for unspecified cases.
Differential Revision: https://phabricator.services.mozilla.com/D146734
This can happen when there is a long nested chain of backdrop-filters
and float inaccuracies cause the final capture primitive to be culled.
Differential Revision: https://phabricator.services.mozilla.com/D147704
layers.
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.
Depends on D128131
Differential Revision: https://phabricator.services.mozilla.com/D128545
This calculates the visible area of the TileCache, and compares against that area
for three purposes:
1) Backdrops must cover only the visible area, not the tile coverage area.
2) Primitives only obstruct the backdrop if they appear in the visible area.
3) Backdrop candidates opaque rects are clipped to the visible area.
All these changes ensure that if a tile coverage area is larger than the window,
backdrops are only considered and created for the visible area.
Note that this has no effect on the contents of tiles that intersect the
backdrop area, wholly or partly. Those tiles, per earlier parts of this
patch, are only set with is_visible=false, which means that they are not
sent to the compositor this frame. The tile surfaces still exist, etc.
This is all in alignment with the idea that we want the entire slice area
(covered by the tiles) to be ready to be scrolled in.
Differential Revision: https://phabricator.services.mozilla.com/D147566
In addition to creating the backdrop surface when it is detected, this also
turns off the rendering of tiles in that same slice. Virtual tiles
associated with compositor surfaces (external or not) will still be
rendered.
This adds a clip check to avoid pushing tiles that are fully clipped out. It
also adds a similar check for compositor surfaces.
Depends on D127175
Differential Revision: https://phabricator.services.mozilla.com/D128131
This only allows native compositors to claim this capability, without changing
any compositors to do so. In Part 4, the macOS native compositor claims this
capability in conjunction with adding the code that handles the color layers.
Differential Revision: https://phabricator.services.mozilla.com/D127175
In bug 1762424 we introduced a rendering path on Android using the
SurfaceControl API, in order to work around a bug preventing recovery
from a GPU process crash. However, the initial implementation caused
this bug: repeatedly sending the same SurfaceControl objects over AIDL
to the GPU process resulted in them being leaked, eventually causing
severe display issues. Not only were we duplicating the SurfaceControl
for each widget, but each time a widget was resized too.
This patch reworks our usage of the SurfaceControl API to avoid ever
having to send them cross-process. Instead, we create a single child
SurfaceControl object for each SurfaceControl that is attached to a
widget. (Typically there will be a single one shared between all
widgets, changing only when the app is paused and resumed, which is
much fewer than one per widget per resize.)
In the parent process we obtain the Surfaces that will be rendered in
to from the child SurfaceControls, and only send those Surfaces to the
GPU process. Thankfully unlike SurfaceControls, sending Surfaces
cross-process does not cause leaks. When the GPU process dies we
simply destroy all of the child SurfaceControls, and recreate them
again on-demand.
Differential Revision: https://phabricator.services.mozilla.com/D147437
In our scroll snap implementation, there's a special handling on a page
scrolling that the closest snap point in the same page before scrolling is prior
to the closest snap point in the next page. There was no test case to test the
behavior.
Differential Revision: https://phabricator.services.mozilla.com/D145849
