Add a way to define an item-local clip-chain from a series of
clips. Port a couple of tests to use this instead of relying on
legacy clip-parenting (which we plan to remove soon).
Differential Revision: https://phabricator.services.mozilla.com/D150662
However, also add a MOZ_ASSERT because GetGeckoContentControllerForRoot()
returning a RemoteContentController here is unexpected and should be
investigated further.
Differential Revision: https://phabricator.services.mozilla.com/D150638
Some more work towards removing the use of legacy clipid parenting
in wrench test files. Add support for specifying the spatial id
without also setting the clip parent. Port some more wrench tests
to use spatial-id and/or clip-chain.
Differential Revision: https://phabricator.services.mozilla.com/D150528
helper_bug982141 was the first APZ test to be run in its own window, a technique
which we've since formalized in runSubtestsSeriallyInFreshWindows().
Rather than having a dedicated test_bug982141 to open its window,
move the subtest into test_group_scrollframe_activation.
Differential Revision: https://phabricator.services.mozilla.com/D150609
nsIGfxInfo::FEATURE_HARDWARE_VIDEO_DECODING is used on all platforms so let's use it on Linux too and don't add new feature for Linux only.
Differential Revision: https://phabricator.services.mozilla.com/D149765
The async front buffer posting is going to be enabled by another bug.
Async IPC was added for async front buffer posting for out-of-process WebGL.
Client does not use TextureClient for storing SurfaceDescriptor.
It works basically same way as to in-process WebGL around nsDisplayCanvas, WebRenderCanvasData, WebRenderCommandBuilder and WebRenderBridgeParent.
SharedSurfaces of SurfaceDescriptorD3D10 are kept alive during their usage. It is for keeping a shread handle valid.
Copied data buffers of SharedShurface_Basics are kept alive during their usage. It is for keeping RenderBufferTextureHost valid.
Differential Revision: https://phabricator.services.mozilla.com/D150197
The async front buffer posting is going to be enabled by another bug.
Async IPC was added for async front buffer posting for out-of-process WebGL.
Client does not use TextureClient for storing SurfaceDescriptor.
It works basically same way as to in-process WebGL around nsDisplayCanvas, WebRenderCanvasData, WebRenderCommandBuilder and WebRenderBridgeParent.
SharedSurfaces of SurfaceDescriptorD3D10 are kept alive during their usage. It is for keeping a shread handle valid.
Copied data buffers of SharedShurface_Basics are kept alive during their usage. It is for keeping RenderBufferTextureHost valid.
Differential Revision: https://phabricator.services.mozilla.com/D150197
Removes the last usage of the old-style clip-id parenting in
gecko. These paths passed the clip parent, but shouldn't be
necessary (all tests pass without them). Landing as a small
patch that's easy to bisect and back out if it does cause any
regression.
Differential Revision: https://phabricator.services.mozilla.com/D150050
Reuse decoder device also to release on intel GPU on Windows, since it is also necessary for zero copy hardware decoded video.
Reuse decoder device handling is also updated as aligned to FEATURE_HW_DECODED_VIDEO_ZERO_COPY.
Differential Revision: https://phabricator.services.mozilla.com/D150448
This patch merges FontFaceSetImpl and gfxUserFontSet into the same
class. This reduces the level of indirection and in theory makes it
easier to manage future threading issues.
Differential Revision: https://phabricator.services.mozilla.com/D147817
For unknown reasons, AVSampleBufferDisplayLayer may sometimes stop
enqueueing new buffers. In this case it will return false for the
readyForMoreMediaData property. When this happens, there's no guarantee
that the layer will ever accept new buffers again. We can work around
this by rebuilding the video layer when it locks up, which ensures that
the video sample is displayed in the next update, seemingly without
visual jitter.
This is not useful if the video enqueueing is failing due to memory
pressure, but more serious failure points would likely be occurring at the
same time.
This patch also adds to the logging we will see when the pref
`gfx.core-animation.specialize-video.log` is set.
Differential Revision: https://phabricator.services.mozilla.com/D149920
This patch merges FontFaceSetImpl and gfxUserFontSet into the same
class. This reduces the level of indirection and in theory makes it
easier to manage future threading issues.
Differential Revision: https://phabricator.services.mozilla.com/D147817
This patch merges FontFaceSetImpl and gfxUserFontSet into the same
class. This reduces the level of indirection and in theory makes it
easier to manage future threading issues.
Differential Revision: https://phabricator.services.mozilla.com/D147817
nsIGfxInfo::FEATURE_HARDWARE_VIDEO_DECODING is used on all platforms so let's use it on Linux too and don't add new feature for Linux only.
Differential Revision: https://phabricator.services.mozilla.com/D149765
Note, this is only applicable to helpers used directly as subtests
in runSubtestsSeriallyInFreshWindows(). It does not apply to:
* Fission test helpers (helper_fission_*.html), which use a separate
subtest mechanism
* Helpers for browser mochitests
* Helpers which are files loaded in an iframe by another helper
Differential Revision: https://phabricator.services.mozilla.com/D150439
Previously, a tile cache backdrop was an opaque color that was guaranteed
to cover the entire tile cache rect. This change makes it so that the
backdrop must only cover the visible area. For compositors that support
native color layers, this allows native color layers to be used more
often.
To make this work, the tile cache background color is updated whenever a
spanning backdrop is found. This ensures that tiles still clear to a
spanning color. The tile cache background is reset on each new scene, so
it won't carry a "stale" backdrop color.
Differential Revision: https://phabricator.services.mozilla.com/D150036
This patch ensures that the calculation for unused temporary buffers can
never overflow via subtraction. Instead of counting buffers as they are
taken from the vec, it just keeps track of how many are left. If a
previous frame has generated a lot of temporary buffers, this will detect
that the current frame didn't use them all.
Differential Revision: https://phabricator.services.mozilla.com/D150271
There's a typo in the condition here, which results in returning CAIRO_INT_STATUS_UNSUPPORTED
in cases where that shouldn't be necessary. Fixing this gets me nice vector PDF output.
The bug is still present in upstream cairo trunk, so I'll report it there as well.
Differential Revision: https://phabricator.services.mozilla.com/D150381
The previous patch in this bug added crash annotations for the number
of total and currently active renderers. However, we are actually
interested in these values when the EGL surface creation fails, as
opposed to when we crash later on after failing to recover. This patch
adds the values to gfxCriticalNote at the time of the error.
Differential Revision: https://phabricator.services.mozilla.com/D150365
In future, it won't be possible to specify clip hierarchy by the
old ClipId identifier, so convert these ones to clip-chains now.
Differential Revision: https://phabricator.services.mozilla.com/D150342
nsIGfxInfo::FEATURE_HARDWARE_VIDEO_DECODING is used on all platforms so let's use it on Linux too and don't add new feature for Linux only.
Differential Revision: https://phabricator.services.mozilla.com/D149765
With the exception of the egde case scenarios in which
IsConnectedToWebRender() returns false.
Also add a comment warning that if RunOnUpdaterThread() were to be called
directly from the updater thread when connected to WebRender, the
implementation would be incorrect.
Differential Revision: https://phabricator.services.mozilla.com/D150309
The earlier name dates back to a time when we could use WebRender
but not necessarily use a WebRender thread as the updater thread.
Also add a comment to list the remaining situatins in which this
function can return false.
Differential Revision: https://phabricator.services.mozilla.com/D150308
Also, no reason not to complete iteration across uTex[012], as opposed
to breaking early once we hit the first one that isn't present.
A shader with e.g. uTex1 but not uTex0 is weird, but there's no reason
for it not to work.
Differential Revision: https://phabricator.services.mozilla.com/D150270
We formerly published webrender to crates.io, but haven't done so in
several years. However, the in-tree version number still matches the
version published on crates.io, causing cargo-vet to flag that this is
something that should potentially be audited. We could silence that on
the cargo-vet side, but then if we ever starting publishing it again
we'd miss the nudge to certify the audit (which would be useful to
anyone consuming it). So bumping the versions to a not-yet-published
number is a good way to correctly articulate the situation.
Differential Revision: https://phabricator.services.mozilla.com/D150055
We formerly published webrender to crates.io, but haven't done so in
several years. However, the in-tree version number still matches the
version published on crates.io, causing cargo-vet to flag that this is
something that should potentially be audited. We could silence that on
the cargo-vet side, but then if we ever starting publishing it again
we'd miss the nudge to certify the audit (which would be useful to
anyone consuming it). So bumping the versions to a not-yet-published
number is a good way to correctly articulate the situation.
Differential Revision: https://phabricator.services.mozilla.com/D150055
We formerly published webrender to crates.io, but haven't done so in
several years. However, the in-tree version number still matches the
version published on crates.io, causing cargo-vet to flag that this is
something that should potentially be audited. We could silence that on
the cargo-vet side, but then if we ever starting publishing it again
we'd miss the nudge to certify the audit (which would be useful to
anyone consuming it). So bumping the versions to a not-yet-published
number is a good way to correctly articulate the situation.
Differential Revision: https://phabricator.services.mozilla.com/D150055
Previously, a tile cache backdrop was an opaque color that was guaranteed
to cover the entire tile cache rect. This change makes it so that the
backdrop must only cover the visible area. For compositors that support
native color layers, this allows native color layers to be used more
often.
To make this work, the tile cache background color is updated whenever a
spanning backdrop is found. This ensures that tiles still clear to a
spanning color. The tile cache background is reset on each new scene, so
it won't carry a "stale" backdrop color.
Differential Revision: https://phabricator.services.mozilla.com/D150036
This allows us to access these prefs off the main thread, e.g. for DOM
workers using OffscreenCanvasRenderingContext2D's text methods.
Differential Revision: https://phabricator.services.mozilla.com/D150124
This doesn't seem to serve any purpose anymore. MOZ_RELEASE_ASSERTing
if mBuildingRect is read during ::Paint doesn't show it happening
anywhere.
Differential Revision: https://phabricator.services.mozilla.com/D150066
This ensures they're clamped on Animated -> sRGB conversion, and in the
future we'll have to implement different color spaces so we'll need to
use it anyways.
Differential Revision: https://phabricator.services.mozilla.com/D149792
`sTiming` is a hack and I believe animation-delay,
animation-iteration-count, animation-direction, and animation-fill-mode
should be meaningful for scroll-linked animations. (I will add the
tentative wpt in Bug 1775327.)
So we need to introduce a normalized timing when resolving the specified
timing.
Also, this patch makes the bug of printing scroll animations detectable.
No behavior is changed and I'd like to remove the magic values and do
normalization in Bug 1775327.
Note: Based on https://github.com/w3c/csswg-drafts/issues/4862 and
web-animations-2, we will introudce CSSNumberish for duration, current
time, and delay. That is, we will accept percentage for
animation-duration, animation-delay. However, Gecko doesn't support
CSSNumberish for those values, so we'd like to normalize these time values
in Bug 1775327. This patch is the 1st step: split the normalized
timing from the specified timing, and use it when resolving the
timing, for progress-based timeline.
Differential Revision: https://phabricator.services.mozilla.com/D149683
This ensures they're clamped on Animated -> sRGB conversion, and in the
future we'll have to implement different color spaces so we'll need to
use it anyways.
Differential Revision: https://phabricator.services.mozilla.com/D149792
Add crash annotations for the total number of webrender renderers, as
well as the number that are currently not paused, as this error could
be caused by having multiple renderers in a resumed state
concurrently. Additionally, add some gfxCriticalNotes for potentially
relevant error cases.
Differential Revision: https://phabricator.services.mozilla.com/D150000
gcc -std=c++20 (but not clang -std=c++20) complains about template class definitions that specify the template parameter on the class constructor.
In file included from /builds/worker/workspace/obj-build/dist/include/nsDisplayList.h:43,
from /builds/worker/workspace/obj-build/dist/include/mozilla/layout/RemoteLayerTreeOwner.h:17,
from /builds/worker/workspace/obj-build/dist/include/mozilla/dom/BrowserParent.h:23,
from /builds/worker/checkouts/gecko/accessible/ipc/other/RemoteAccessible.cpp:13:
/builds/worker/workspace/obj-build/dist/include/mozilla/layers/BSPTree.h:30:18: error: expected ')' before '*' token
| BSPPolygon<T>(T* aData, gfx::Polygon&& aGeometry)
| ~ ^
Differential Revision: https://phabricator.services.mozilla.com/D149813
Right now we rely on the menulist to be injected by hand in all the
relevant windows. Instead create it lazily, making the select code more
standalone.
The DevTools window was missing it, for example.
Differential Revision: https://phabricator.services.mozilla.com/D149620
Some VA-API drivers are so broken that trying to use them
crashes Firefox. This is nothing entirely new for GPU drivers
and which is why we have `glxtest`.
Thus move the test from `VAAPIUtils` there. This has the
additional benefit of only doing the test once.
Given the importance of GL-accelerated rendering these days,
we don't want failing VA-API drivers to disable hardware
Webrender and WebGL. Thus fork the VA-API test into its
own process.
Differential Revision: https://phabricator.services.mozilla.com/D148981
If it's static, every translation unit gets its own copy of
the static local variable sStartupTime.
Since it's defined in a header, we make it inline instead.
Differential Revision: https://phabricator.services.mozilla.com/D149811
Depending on the current transform, Skia applies either subpixel rounding or integer
rounding to different coordinate axes of the transformed glyph position. If we don't
correctly predict which of these are applied, we may have aliased cache entries that
round to the same value in DrawTargetWebgl but for which Skia under the hood rounds
in entirely different directions. When this happens, glyphs can get hinted to the
wrong direction. To fix this, we need to ensure that we appropriately apply either
subpixel rounding or integer rounding in the same manner as Skia.
Differential Revision: https://phabricator.services.mozilla.com/D149350
This applies a fix that is present in Skia's HW luminosity blend mode to its
CPU pipeline so that the luminosity mode no longer divides by zero, thus avoiding
infs and nans.
Differential Revision: https://phabricator.services.mozilla.com/D149030
This applies a fix that is present in Skia's HW luminosity blend mode to its
CPU pipeline so that the luminosity mode no longer divides by zero, thus avoiding
infs and nans.
Differential Revision: https://phabricator.services.mozilla.com/D149030
Including glean_parser 6.1.1
Two important things in there:
* glean_parser: [data-review] Include extra keys' names and descriptions in data review template
* Glean: Derive `serde::{Deserialize, Serialize}` on `Lifetime` and `CommonMetricData`
Differential Revision: https://phabricator.services.mozilla.com/D149381
This in-out parameter business used to be necessary (bug 1249279), but
we don't propagate the new widget scale to remote documents (which are
the common case now) and we seem to be doing just fine without that, so
I'm not sure why this would be needed anymore.
Also simplify some unit conversions while at it.
Differential Revision: https://phabricator.services.mozilla.com/D149032
In bug 1773342 I made OS text scale factor behave like a full zoom
factor which applies to all pages (including the browser chrome). That's
generally straight forward but it makes some callsites that use unzoomed
CSS coordinates misbehave (or behave correctly accidentally actually in
some other cases).
The main fix here is making
nsIBaseWindow::UnscaledDevicePixelsPerCSSPixel() and
nsIScreen::GetDefaultCSSScaleFactor() account for OS zoom as necessary.
However, I also went through the relevant code and cleaned it up to use
typed units and operations when possible.
The setup means:
* nsIWidget::GetDefaultScale() doesn't account for OS full zoom.
* nsIBaseWindow and nsIScreen does.
These are the places where this should matter and stuff can get
confused, but this works surprisingly well for all callers (except one
nsDeviceContext one which we use only for PuppetWidget and we can
remove by falling back to 1.0 like all other widgets until the update
comes).
Differential Revision: https://phabricator.services.mozilla.com/D149033
In bug 1773342 I made OS text scale factor behave like a full zoom
factor which applies to all pages (including the browser chrome). That's
generally straight forward but it makes some callsites that use unzoomed
CSS coordinates misbehave (or behave correctly accidentally actually in
some other cases).
The main fix here is making
nsIBaseWindow::UnscaledDevicePixelsPerCSSPixel() and
nsIScreen::GetDefaultCSSScaleFactor() account for OS zoom as necessary.
However, I also went through the relevant code and cleaned it up to use
typed units and operations when possible.
The setup means:
* nsIWidget::GetDefaultScale() doesn't account for OS full zoom.
* nsIBaseWindow and nsIScreen does.
These are the places where this should matter and stuff can get
confused, but this works surprisingly well for all callers (except one
nsDeviceContext one which we use only for PuppetWidget and we can
remove by falling back to 1.0 like all other widgets until the update
comes).
Differential Revision: https://phabricator.services.mozilla.com/D149033
On multi-GPU setups, EGLs "surfaceless" platform may pick the wrong device.
There is a very recent extension which solves this issue,
`EGL_EXT_explicit_device`, however it states:
> Using EGL_EXT_explicit_device with EGL_MESA_platform_surfaceless is
> functionally identical to EGL_EXT_platform_device.
Thus, if we previously detected a render node device, use
`EGL_EXT_platform_device` to create the display in headless scenarios.
For all other cases, notably ARM SOCs where
`EGL_DRM_RENDER_NODE_FILE_EXT` is not yet availble, continue to
fall back to the surfaceless platform.
Note: this patch also does some cleanups. Most importantly,
`EGL_MESA_platform_surfaceless` is a client extension, not a
display extension. The check for it must thus always have failed.
Instead, check for it before trying to use it when creating the
display.
Also remove the rendundant redifinition in `GLDefs.h` - it's
already included in the upstream EGL headers.
Differential Revision: https://phabricator.services.mozilla.com/D148946
This is a purely speculative attempt to fix bug 1772839. The theory
being perhaps that due to the EGL Surface being current,
eglDestroySurface does not detach it from the Android Surface. This
would cause the subsequent eglCreateWindowSurface to fail as the
Android Surface is still attached.
Differential Revision: https://phabricator.services.mozilla.com/D149147
Now that cbindgen and rust support const generics, it seems more simple.
This centralizes all the relevant font constants etc in rust and avoids
conversions when going from rust to C++ and vice versa.
Differential Revision: https://phabricator.services.mozilla.com/D148847
In bug 1773342, I made OS text zoom behave like layout full zoom on all
pages (including the main browser page).
This means that getting CSS pixels from the browser page and turning
them to LayoutDevice pixels by multiplying by GetDefaultScale() isn't
right.
However, the caller already has the right device pixel values, so just
use them.
Differential Revision: https://phabricator.services.mozilla.com/D149026
As part of the frame building work being done, the PrimitiveInstance
struct will change significantly (most of the state will be moved
to the primitive template, instance will be closer to an index +
some visibility state).
`prepared_frame_id` is no longer relevant (it can't be incorrect
now due to the way prims are reset). The chase is is not used or
maintained, and would need to be quite different after the changes
mentioned above anyway.
Differential Revision: https://phabricator.services.mozilla.com/D149025
Now that cbindgen and rust support const generics, it seems more simple.
This centralizes all the relevant font constants etc in rust and avoids
conversions when going from rust to C++ and vice versa.
Differential Revision: https://phabricator.services.mozilla.com/D148847
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
Since backdrop_surface is not cleared on prepare_for_new_scene, it's possible
that the tile cache might be carrying "old" backdrop info. Existing code
correctly handles this case *as long as* the new scene also has a backdrop.
This change is necessary to make sure that old backdrop info is cleared
even when the new scene does not contain a backdrop.
Differential Revision: https://phabricator.services.mozilla.com/D148848
It's not necessary to clear the tile cache backdrop surface when a new
scene arrives. Doing so has unintended consequences because clearing the
backdrop surface forces the destruction of the associated native surface.
That native surface will very likely just have to be recreated. If the new
scene doesn't have a backdrop, or has a different backdrop, the logic in
take_context is sufficient to destroy the old one.
Depends on D148704
Differential Revision: https://phabricator.services.mozilla.com/D148705
This ensures that the native surfaces for color backdrops are destroyed
when the tile cache itself is destroyed.
Depends on D148678
Differential Revision: https://phabricator.services.mozilla.com/D148704
It's not necessary to clear the tile cache backdrop surface when a new
scene arrives. Doing so has unintended consequences because clearing the
backdrop surface forces the destruction of the associated native surface.
That native surface will very likely just have to be recreated. If the new
scene doesn't have a backdrop, or has a different backdrop, the logic in
take_context is sufficient to destroy the old one.
Depends on D148704
Differential Revision: https://phabricator.services.mozilla.com/D148705
This ensures that the native surfaces for color backdrops are destroyed
when the tile cache itself is destroyed.
Depends on D148678
Differential Revision: https://phabricator.services.mozilla.com/D148704
- Update SharedSurfaceDMABUF for EGL_MESA_image_dma_buf_export DMABufSurface interface.
- Test surface export and import in SurfaceFactory_DMABUF::CanCreateSurface() to make sure it really works.
Depends on D147636
Differential Revision: https://phabricator.services.mozilla.com/D147637
This patch is rolling back changeset 06c57c0af21d which is Phabricator
revision D147566, plus adding some comments indicating the desire to
restore some of the intent of that code. The effect of this rollback is to
activate native color layers only if they cover the entire scrollable
area, not just the visible area. This is necessary to ensure correct
visuals as tiles are scrolled into view, when those tiles show something
other than the backdrop color.
Differential Revision: https://phabricator.services.mozilla.com/D148541
Add a dom/base/rust crate called just "dom" where we can share these.
Most of the changes are automatic:
s/mozilla::EventStates/mozilla::dom::ElementState/
s/EventStates/ElementState/
s/NS_EVENT_STATE_/ElementState::/
s/NS_DOCUMENT_STATE_/DocumentState::/
And so on. This requires a new cbindgen version to avoid ugly casts for
large shifts.
Differential Revision: https://phabricator.services.mozilla.com/D148537
The duplications arise from a Glean update, which has some of those as
transitive dependencies.
Upgrading Clap and others here reduces the duplication.
Differential Revision: https://phabricator.services.mozilla.com/D147659
Upgrades to Glean v50.0.1, which comes with a rewritten core and
UniFFI-powered bindings.
Glean has some API changes, so we swap it over to that. Mostly mechanical changes.
Also upgrades to inherent v1.0 in fog.
This matches what Glean uses internally and gets rid of one duplicated crate.
Also upgrades to glean-parser==6.0.1
One crate duplication now (change in `python/mozbuild/mozbuild/vendor/vendor_rust.py` required).
Some new crates now vendored.
These are transitive dependencies of Glean dependencies, all with valid
licenses and already used in other products (mobile).
Differential Revision: https://phabricator.services.mozilla.com/D146062
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
Kelsey Gilbert
Glenn Watson
criss
Botond Ballo
stransky
sotaro
Norisz Fay
Andrew Osmond
Jim Blandy
Brad Werth
Marian-Vasile Laza
Michael Froman
Nico Grunbaum
Bogdan Szekely
Michelle Goossens
Iulian Moraru
Jonathan Kew
Jamie Nicol
Lee Salzman
Bobby Holley
Narcis Beleuzu
David Shin
Jeff Muizelaar
Emilio Cobos Álvarez
Boris Chiou
Mike Conley
serge-sans-paille
Chris Peterson
Robert Mader
Butkovits Atila
Jan-Erik Rediger
Razvan Cojocaru
Dan Robertson
Nicolas Silva
Noemi Erli
Mike Hommey
Stephen A Pohl
Nika Layzell
Sylvestre Ledru
Molnar Sandor
Ryan VanderMeulen
Bas Schouten
Olli Pettay
Timothy Nikkel
Ashley Hale
Tom Ritter
Miko Mynttinen
Sergio Villar Senin
Hiroyuki Ikezoe