As started in https://github.com/servo/servo/issues/42168 let's report
memory pressure for webgl objects. CanvasContexts report memory twice:
once because of underlying texture object and once by themself, but
that's okay as we also need to account for swapchain textures.
Computing exact size would be to much work and code so we report rough
estimations.
Testing: None
Signed-off-by: sagudev <16504129+sagudev@users.noreply.github.com>
This moves WebGL component from IpcChannel to GenericChannel. Of note
are the following changes:
- Removal of WebGlSender and WebGlReceiver type alias. As we removed
them in a similar component earlier.
- Moving from IpcByteSender to IpcSender over serde_bytes::ByteBuf. I
think the tradeoff for easier reading is worth it.
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
Testing: Compilation and unit tests.
---------
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
Co-authored-by: Sam <16504129+sagudev@users.noreply.github.com>
Changed most #[allow]s to #[expect]s, mainly for
clippy::too_many_arguments
Removed unfulfilled expectations
This is my first opensource contribution, so please let me know if
anything should
be done differently.
Testing: Refactor
Part of: #40838
---------
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
Signed-off-by: TimurBora <timurborisov5561@gmail.com>
Co-authored-by: Tim van der Lippe <TimvdLippe@users.noreply.github.com>
In the future, servo components should depend on the generic channels in
base instead of IpcChannels to correctly optimize for multiprocess vs
non-multiprocess mode.
This reexports IpcSharedMemory as GenericSharedMemory in GenericChannel
and changes all dependencies on it.
Currently this is only a type/name change and does not change
functionality. But in the future we would want want to use non-ipc
things for the data.
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
Testing: This changes types and does not need testing.
---------
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
Changed some allow to expects and removed the unfulfilled expectations.
Testing: Refactor
Part of: #40383
Signed-off-by: anonmiraj <nabilmalek48@gmail.com>
Many WebGL objects refer to a `WebGLRenderingContext` and rely on it for
messaging to the `WebGLThread`. This poses a problem, because WebGL
objects often need to send a message to the `WebGLThread` during their
`Drop` implementation. If the `Drop` is triggered as part of garbage
collection, references to the `WebGLRenderingContext` might be invalid,
if they were garbage collected first as part of the same harvest.
This change makes it so that all of these objects store a `WeakRef`
instead of a `Dom<>`. The `WeakRef` is only used if it can be rooted,
otherwise a `ContextLost` error is given. In cases where only messaging
is needed, a cloned `WebGLMsgSender` is used to perform messages
regardless of whether the context is garbage collected or not.
This isn't a replacement for #37622, but should make it easier to
implement as
the `WebGLMsgSender` and the `WeakRef` could be stored in the droppable
portion of the DOM object.
Testing: This fixes a use-after-free issue which is mainly detectable
via ASAN
builds. Since we do not run ASAN on CI, this is a bit hard to create
automated
tests for. I verified that this fixed the issue manually.
Fixes: #40655.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
CanvasContext: follow spec for isSync and isTransformFeedback
Testing: more CanvasContext test will pass.
Signed-off-by: Taym Haddadi <haddadi.taym@gmail.com>
Removes some unneeded lints, especially `#[allow(unsafe_code)]`.
Testing: Refactor
Part of: #40383
Signed-off-by: WaterWhisperer <waterwhisperer24@qq.com>
This change makes it so that the `HTMLCanvasElement` is responsible for
managing the `ImageKey` for associated `RenderingContext`s. Only
canvases display their contents into WebRender directly, so this makes
it so that keys are not generated for `OffscreenCanvas`.
The main goal here is that `ImageKey`s are always associated with a
particular `WebView`, which isn't possible in the various canvas
backends yet. This is important because each `WebView` may soon have a
different WebRender instance entirely with its own set of `ImageKey`s.
This also allows for clearing `ImageKey`s when canvases are disconnected
from the DOM in a future change. One tricky thing here is placeholder
canvases, which are meant to be driven from workers.
It seems that the implementation isn't correct for these at the moment
as they need to be updated to the specification. Instead, what is
happening is that any existing context / image is completely lost when
converting to an `OffscreenCanvas`.
Testing: This shouldn't change observable behavior, so is covered by
existing tests.
Fixes: This is part of #40261.
---------
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Signed-off-by: Mukilan Thiyagarajan <mukilan@igalia.com>
Co-authored-by: Mukilan Thiyagarajan <mukilan@igalia.com>
Servo has a lot of comments like this:
```rust
// https://example-spec.com/#do-the-thing
fn do_the_thing() {}
```
and I keep turning these into doc comments whenever I'm working close to
one of them. Doing so allows me to hover over a function call in an IDE
and open its specification without having to jump to the function
definition first. This change fixes all of these comments at once.
This was done using `find components -name '*.rs' -exec perl -i -0777
-pe 's|^([ \t]*)// (https?://.*)\n\1(fn )|\1/// <$2>\n\1$3|mg' {} +`.
Note that these comments should be doc comments even within trait `impl`
blocks, because rustdoc will use them as fallback documentation when the
method definition on the trait does not have documentation.
Testing: Comments only, no testing required
Preparation for https://github.com/servo/servo/pull/39552
---------
Signed-off-by: Simon Wülker <simon.wuelker@arcor.de>
Any RenderingContext/OffscreenRenderingContext type has readonly
"canvas" attribute
and associated native-code DOM context objects have reference to target
DOM canvas objects.
https://html.spec.whatwg.org/multipage/canvas.html#renderingcontexthttps://html.spec.whatwg.org/multipage/canvas.html#offscreenrenderingcontext
And currently the reference to DOM canvas object is the rooting pointer
on the stack,
which leads to the circular reference problem.
The SpiderMonkey's (SM) garbage collector will not be able to free the
DOM canvas and context
objects (unreacheble from JS) because of the rooting pointer on stack
(see STACK_ROOTS).
And these objects will be stored until the associated script
runtime/thread will be terminated.
SM -> JS Roots -> DOM Canvas* (on heap) -> DOM Context (on heap)
SM -> Rust Roots -> Dom Canvas* (on stack) <- as "canvas" member field
Let's replace the rooting pointer to the traceble pointer (DomRoot ->
Dom)
in the "canvas" member field of DOM context object, which allows to
broke circular referencing problem.
Testing: No changes in existed tests
Signed-off-by: Andrei Volykhin <volykhin.andrei@huawei.com>
Co-authored-by: Andrei Volykhin <volykhin.andrei@huawei.com>
Adds epoch to each WR image op command that is sent to compositor. The
renderer now has a `FrameDelayer` data structure that is responsible for
tracking when a frame is ready to be displayed. When asking canvases to
update their rendering, they are given an optional `Epoch` which denotes
the `Document`'s canvas epoch. When all image updates for that `Epoch`
are seen in the renderer, the frame can be displayed.
Testing: Existing WPT tests
Fixes: #35733
Signed-off-by: sagudev <16504129+sagudev@users.noreply.github.com>
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Martin Robinson <mrobinson@igalia.com>
Move interfaces defined by the WebGL spec to the `script/dom/webgl/
`module from `script/dom/`.
`script/dom/webgl*.rs` -> `script/dom/webgl/`
`script/dom/webgl_extensions` -> `script/dom/webgl/extensions`
`script/dom/webgl_validations` -> `script/dom/webgl/validations`
Testing: No changes, just a refactoring
Fixes (partially): #38901
Signed-off-by: Andrei Volykhin <volykhin.andrei@huawei.com>
Co-authored-by: Andrei Volykhin <volykhin.andrei@huawei.com>
