Inspired by emilio's suggestion in the shader module API patch. This tries to be the most straightforward way to go from the strings coming from IPC to the ones consumed by wgpu.
Differential Revision: https://phabricator.services.mozilla.com/D151024
This patch is a lot of plumbing for not that much functionality. The goal is to align CreateShaderModule's error reporting with the spec.
Creating a shader module is now a dedicated async IPDL message returning the compilation info so that it can be exposed as a promise by the WebGPU API.
Differential Revision: https://phabricator.services.mozilla.com/D146817
When Surfaces/SurfaceTextures are allocated they are given a handle,
which is a monotonically increasing 32-bit integer. To render
Surfaces, we typically pass the Surface handle to the compositor,
which then looks it up in a map to find the corresponding
SurfaceTexture.
Following a GPU process restart, content may be left with stale
handles referencing SurfaceTextures which no longer exist. Once new
SurfaceTextures are allocated, these stale handles may reference new
SurfaceTextures with no relation to the old handle. This can lead to
rendering the wrong texture. Additionally, we may crash when
allocating "sync" SurfaceTextures, as the previous sync texture for a
certain handle may not have been released yet.
To fix this, this patch combines the existing handle with a new ID
uniquely identifying the process in which the SurfaceTexture was
allocated (or 0 for the parent process). We use a monotonically
increasing value rather than the pid to guard against the new GPU
process possibly having the same pid as the previous instance. We
combine these two 32-bit integers and use the resulting 64-bit integer
as the Surface handle.
Differential Revision: https://phabricator.services.mozilla.com/D150963
The `widget->DispatchInputEvent` codepath only works in gecko CI
configurations, so to allow this to be used for e.g. WebDriver
implement a path that doesn't go via the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D150632
This patch is a lot of plumbing for not that much functionality. The goal is to align CreateShaderModule's error reporting with the spec.
Creating a shader module is now a dedicated async IPDL message returning the compilation info so that it can be exposed as a promise by the WebGPU API.
Differential Revision: https://phabricator.services.mozilla.com/D146817
The last row of data may have less than stride bytes so make sure we
only copy what we need.
This corresponds to cairo:cccc81ccba99600483621e02ae9438a4a5a3d024
Differential Revision: https://phabricator.services.mozilla.com/D151053
This is mostly just changing a small number of structs and function
params (most of the work has been done in previous patches).
Differential Revision: https://phabricator.services.mozilla.com/D150987
Also make the parent in ClipTemplate an Option, so that the
semantics are a bit clearer (follow up patches will remove this
parent field entirely).
Differential Revision: https://phabricator.services.mozilla.com/D150980
Use the animation id from the stacking context to find the hit-testing tree node
for hit tests of elements that are sticky positioned. Then use this hit-testing
tree node reference to apply APZ transforms if the sticky positioned element is
stuck to the root content.
Differential Revision: https://phabricator.services.mozilla.com/D150047
## Summary
Pass the fixed position element animation id through webrender, returning the
the animation id in the hit-test result if the element is a fixed position
element. This animation id then can be used to lookup the relevant Hit-Testing
Tree Node, which can be used to find the fixed (or sticky) position side bits.
## Motivation
Sticky content can be currently stuck to the root content or not, based on the
scroll position. As a result, when hit testing sticky content, APZ needs both
the sticky position side bits and additional information to determine if the
element is currently stuck to the root content. This is needed to fix the
hit-testing of sticky position content when a APZ transform is being applied,
such as overscroll and hiding the dynamic toolbar.
## Implementation
The information needed to determine if a element is currently stuck to the root
content and the fixed/sticky position side bits is already stored in the
hit-testing tree node. Any hit test result should have a corresponding
hit-testing tree node entry. When a hit-test result contains a animation id and
a hit-testing tree node is found, we can store a pointer to this node and use
this to check the fixed/sticky position side bits. Something similar is already
done for hit test results when a scrollbar is hit.
Differential Revision: https://phabricator.services.mozilla.com/D148648
The `widget->DispatchInputEvent` codepath only works in gecko CI
configurations, so to allow this to be used for e.g. WebDriver
implement a path that doesn't go via the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D150632
This removes the last piece of code in wrench and gecko (there is
one more callsite in WR itself) that relies on the legacy clip
parenting code.
Differential Revision: https://phabricator.services.mozilla.com/D150694
The `widget->DispatchInputEvent` codepath only works in gecko CI
configurations, so to allow this to be used for e.g. WebDriver
implement a path that doesn't go via the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D150632
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