The "Preferences" -> "Settings" changes have been reverted so this can land now. Those string changes will be handled in bug 1694511.
Differential Revision: https://phabricator.services.mozilla.com/D105577
Despite having to move around some code into other files, this patch actually
changes very little inside composite.h and swgl_ext.h. It makes linear_row_yuv
able to call blend_pixels, and in turn makes blendYUV call that version of it.
This prevents cases where we have to blend video (because of clip masks) from
falling off the fast path.
To allow this, I had to move out blend stage code into blend.h so that it can
be called from inside composite.h. While I was at it, it made sense to factor
out the rasterization stage into its own rasterize.h file as well, as gl.cc
has grown significantly...
Differential Revision: https://phabricator.services.mozilla.com/D106261
This requires us to plumb CompositorCapabilities to support the extra field.
This is complicated by the fact that since it is a Rust struct, it has no
default constructor that can pass through to C++ via bindings, so every
one of our RenderCompositors was forced to manually initialize fields. To
get around this brittle footgun, instead the structure is initialized on
the Rust side, and RenderCompositor's are encouraged to only change fields
that actually diverge from the defaults as passed in via pointer.
Finally, we can then do what we need to do, which is just to send the
ForceRedraw message that needs to happen based on what we know about
CompositorCapabilities.
Differential Revision: https://phabricator.services.mozilla.com/D106246
This wasn't needed and could introduce unnecessary delays, so we do all the calls
at the same time and then await for all the calls to be settled.
Differential Revision: https://phabricator.services.mozilla.com/D105944
If there was multiple concurrent calls to listStores, only the last one made would
resolve, the other one would be stuck indefinitely.
This was caused by the call to indexedDb actor `preListStores` method, in which
the `hostVsStores` is reset to an empty Map. So if there was still a previous
pending call, one of the promise who was relying on an entry being in `hostVsStores`
would never resolve.
To prevent this, we cache the pending promise when calling `preListStores` so any
concurrent calls would wait for the same promise.
A test is added to make sure we don't regress in the future.
Differential Revision: https://phabricator.services.mozilla.com/D105943
FunctionRef is so easily inlineable, looking at the comments in D95354.
This also removes some duplication, so it's win-win.
I fixed the assertion to restore the original meaning, since it seems it
was accidentally changed in that revision.
Also added some comments on why the different ordering for removals and
non-removals.
Differential Revision: https://phabricator.services.mozilla.com/D106265
We don't override any of the methods. I wonder when this stopped being
useful, it seemed useless before bug 1420547 already, and the comment
oes back to bug 342062...
Differential Revision: https://phabricator.services.mozilla.com/D106268
This patch only erases some of the differences between how pictures and other primitves resolve their render tasks. There is a lot more to do there but I quite haven't figured out the incremental next step towards decoupling the picture primitive its content. After this patch we may be close to a good place to start extracting composite modes out into their own primitives.
Differential Revision: https://phabricator.services.mozilla.com/D106142
65k render tasks is a lot more than what we need, and RenderTaskId will soon be stored in more places where size affects performance.
Differential Revision: https://phabricator.services.mozilla.com/D105986
The test render tasks used to dodge the gpu cache interactions. Rather than maintain special cases, make it so the gpu cache is usable during these tests (which mainly means having a valid frame stamp to not trigger some assertions).
Differential Revision: https://phabricator.services.mozilla.com/D105985
This is the last important change of this render task refactoring. Cached render tasks now create nodes in the frame graph so that they can be referenced via a render task ID. With this it is now possible to refer to almost any textured content via a render task ID, regardless of how it was produced and whether it is cached. It also allows any render task to read from a cached one (before, only primitives and clip sources could).
This obsoletes ImageSourceHandle which will be remvoed in a subsequent patch.
Differential Revision: https://phabricator.services.mozilla.com/D105952
The accordion widget inside the response view of the Network Monitor got replaced by a simple headline with a toggle button at the end.
Differential Revision: https://phabricator.services.mozilla.com/D103839
This requires us to plumb CompositorCapabilities to support the extra field.
This is complicated by the fact that since it is a Rust struct, it has no
default constructor that can pass through to C++ via bindings, so every
one of our RenderCompositors was forced to manually initialize fields. To
get around this brittle footgun, instead the structure is initialized on
the Rust side, and RenderCompositor's are encouraged to only change fields
that actually diverge from the defaults as passed in via pointer.
Finally, we can then do what we need to do, which is just to send the
ForceRedraw message that needs to happen based on what we know about
CompositorCapabilities.
Differential Revision: https://phabricator.services.mozilla.com/D106246
This patch is developed from D104136#3396152.
This patch creates WorkerTestUtils.webidl under dom/webidl for testing workers with internal APIs. These APIs are exposed to workers only and controlled by dom.workers.testing.enabled pref.
This patch creates a Mozilla-specific web-platform test, testing/web-platform/mozilla/test/workers/worker_timer_nesting_level.html, to test the timer nesting level implementation for workers.
To simplify the test implementation, this patch does not implement the webidl under dom/chrome-webidl/ suggested by D104136#3396152.
Depends on D104136
Differential Revision: https://phabricator.services.mozilla.com/D105332
