- canvas
- constellation_traits
- canvas_traits
- constellation
Testing: This should not change any behaviour.
---------
Signed-off-by: Euclid Ye <yezhizhenjiakang@gmail.com>
Moves the cleanup logic to a separate helper struct to comply with the
prohibition of manual `Drop` implementations for DOM types.
Testing: WebGL tests just cover its cases
Fixes: Partially #26488
Signed-off-by: Domenico Rizzo <domenico.rizzo@gmail.com>
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>
Reviewable per commits:
As noted in
https://github.com/servo/servo/pull/42180#discussion_r2749861902
transmuting `&Reflector<AssociatedMemory>` to `&Reflector<()>` will
ignore AssociatedMemory information and thus it will not remove extra
associated memory. By returning `&Reflector<Self::ReflectorType>` from
`DomObject::reflector()` we will preserve this information and thus
correctly handle cases with associated memory. We also do not need
`overrideMemoryUsage` in bindings.conf anymore. 🎉
Instead of removing associated memory in drop code we should do it as
part of finalizers, otherwise we have problems in nested (inherited)
structs, where drop is run for both parent and child, but we only added
associated memory for child (on init_reflector) which already included
size of parent. The only exception here is promise, because it is RCed
and not finalized.
Testing: Tested locally that it fixes speedometer.
Fixes#42269
---------
Signed-off-by: sagudev <16504129+sagudev@users.noreply.github.com>
By reporting memory usage of rust objects back to SM it can trigger GC
sooner and release more memory (I hope that we could use this to avoid
OOB in webgpu in the future).
Currently we use simple `size_of::<DomStruct>() +
size_of::<Box<DomStruct>>()` but it's possible to override reported
memory with `update_memory_size(self, nbytes);` on reflector. This is
mostly useful for canvases and buffers which usually have large
associated data.
Testing: None, but I am wondering if we can connect this to
`about:memory`.
Fixes: #42168
---------
Signed-off-by: sagudev <16504129+sagudev@users.noreply.github.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>
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>
