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
The test assumes that mousemove events are fired with waiting a tick
after synthesizing native mousemove event. However, it's wrong since
synthesizing native mousemove event may run after a tick for waiting
safe time to synthesize a native event.
Differential Revision: https://phabricator.services.mozilla.com/D106136
For the case the consumer needs heap-allocated ExtensibleCompilationStencil,
make CompileGlobalScriptToStencilAndMaybeInstantiate possible to also return
ExtensibleCompilationStencil.
Differential Revision: https://phabricator.services.mozilla.com/D105898
To support instantiating without heap-allocate CompilationStencil, modify
CompileGlobalScriptToStencil to receive either CompilationStencil pointer or
CompilationGCOutput pointer, and if CompilationGCOutput pointer is passed,
instantiate it internally.
Differential Revision: https://phabricator.services.mozilla.com/D105897
Make all classes to follow init() + compile() + stencil().
stencil() returns a reference to ExtensibleCompilationStencil, and consumer
can either use BorrowingCompilationStencil to create temporary
CompilationStencil from it, or use ExtensibleCompilationStencil::finish to
get non-temporary CompilationStencil.
Differential Revision: https://phabricator.services.mozilla.com/D105896
Instead of directly storing into CompilationStencil, store all data into
CompilationState, from Parser and BytecodeEmitter.
Differential Revision: https://phabricator.services.mozilla.com/D105145
