Canvas expects input data to be in RGBA premultiplied format and
WebRender already supports RGBA and BGRA data as long as they are
premultiplied. Pre-multiplying up front allows:
- Avoiding many conversions when painting images to canvas.
- Passing the `RasterImage` IpcSharedMemory of the image instead of
creating
a new one with the premultiplied data every time we upload to
WebRender. This is a big deal for animated gifs, because before every
frame was creating a new shared memory segment.
It seems that for rasterized SVGs were were already putting
premultplied data into the `RasterImage` so it's quite likely SVGs were
being composited incorrectly.
Testing: This causes 8 tests to start passing and 2 tests to fail in the
WebGL conformance suite.
The failures are due to the fact that premultiplying alpha is lossy when
alpha is 0. In that case,
the resulting color of a blend operation might be wrong. This is
typically only a problem if you
use RGBA data as RGB data, which is pretty unusual. In the case that you
are blending with
RGBA the final color values will be 0 or close to 0 anyway. Gecko solves
this issue by having a
cacheable surface generation API that can fetch both premulitplied and
unpremulitplied data
from things like image elements. We do not have that yet, but I argue
that this change
is important anyway due to the amount that it reduces memory and file
descriptor usage
as well as the cost of copying image data so much in memory.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Now that we do not need to call `Node::dirty` when an image frame
changes, we no longer have to keep a map of rooted nodes. Instead,
expose a new `AnimatingImages` type that also tracks when the set of
animating images is diryt and new image animation update should maybe be
scheduled.
In addition, cancel any ongoing image animations eagerly when they are
removed from the DOM like we do for CSS animations.
Testing: This should not change behavior and thus is covered by existing
WPT tests.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Mukilan Thiyagarajan <mukilan@igalia.com>
Add a new super-lightweight layout mode that avoids any layout when
canvas is updated or animated images progress to the next frame. In the
future this can also be used for video elements.
Testing: This is a performance optimization, so shouldn't change any
WPT test results.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Mukilan Thiyagarajan <mukilan@igalia.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>
Instead of manually triggering `ScriptThread::update_the_rendering`,
have animated images trigger rendering updates via the `ScriptThread`
event loop. This should result in fewer calls to
`ScriptThread::update_the_rendering`.
Testing: This should not change behavior and is thus covered by existing
tests.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Mukilan Thiyagarajan <mukilan@igalia.com>
Instead of iterating through all frames every time we are looking for a
particular frame, just index into the `Vec` of frames directly. This
should do less work on every frame transition.
Testing: This is just a small optimization, so shouldn't change
observable
behavior.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
This change fixes an issue and makes a few more minor improvements to
the `ImageAnimationState`:
1. Image rooting and unrooted now happens in one step from
`Window::update_animations_post_reflow`.
2. The `node_to_animating_image_map` is now stored as a shared `RwLock`
so that it doesn't need to be taken and then replaced in the
`ImageAnimationState` during reflow. This should prevent a hypothetical
issue
where image animations are restarted during empty reflows.
3. General naming and idiomatic Rust usage improvements.
Testing: This doesn't really have any obvious behavioral changes,
because all
reflows currently trigger a restyle. It becomes a serious problem with
#37677
and this change fixes the failing test there.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Now that we are standardizing on the `_traits` crates becoming `_api`
and exposing the API of the crate that they get their name from [^1],
`script_layout_interface` becomes `layout_api` as it exposes the API for
`layout` that is used by `script` This brings the crate in line with the
naming of the other ones in `shared`.
[^1]:
https://servo.zulipchat.com/#narrow/channel/263398-general/topic/Organizing.20*_traits.20crates/with/396893711
Testing: This should not change any behavior and thus is covered by
existing tests.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
The default of `enum-variant-name-threshold` is 3, so adding any new
variants will lead to the lint being triggered, reference:
[enum_variant_names](https://rust-lang.github.io/rust-clippy/master/index.html#enum_variant_names).
This PR fix this potential clippy lint warning for facilitate the
addition of new variant in following PR about incremental box tree
update.
Testing: No logic changed, just covered by existing WPT tests
Fixes: None
Signed-off-by: sharpshooter_pt <ibluegalaxy_taoj@163.com>
