2023-05-10 14:36:43 -03:00
|
|
|
/*
|
2024-10-04 08:19:50 -03:00
|
|
|
* Copyright (c) 2023, Andreas Kling <andreas@ladybird.org>
|
2023-05-10 14:36:43 -03:00
|
|
|
*
|
|
|
|
|
* SPDX-License-Identifier: BSD-2-Clause
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <LibWeb/HTML/DecodedImageData.h>
|
|
|
|
|
|
|
|
|
|
namespace Web::HTML {
|
|
|
|
|
|
2026-06-14 07:04:42 -03:00
|
|
|
void DecodedImageData::Client::register_with_decoded_image_data_if_needed()
|
|
|
|
|
{
|
|
|
|
|
auto const& image_data = decoded_image_data();
|
|
|
|
|
|
|
|
|
|
if (!image_data)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
image_data->m_clients.set(this);
|
LibWeb: Transfer animation ownership to `AnimatedBitmapDecodedImageData`
Previously animation ownership was a messy split between
`AnimatedBitmapDecodedImageData` and the consumers (i.e.
`ImageStyleValueResource`, `HTMLImageElement`, and `SVGImageElement`)
with `AnimatedBitmapDecodedImageData` owning the frames and a current
frame index, and the consumers owning the rest of the state (e.g. loop
count, timers to drive the animation forward, their own current index).
This had a couple of main issues:
- While `AnimatedDecodedImageData` partially synchronized animations by
dropping unexpected advancement notifications, this didn't apply to
other animation state which meant, for instance, that a later started
consumer could drive the animation of an earlier one past the max
loop count (albeit without invalidating the earlier consumer).
- Multiple consumers didn't share frame timings, meaning animations
could be up to a full frame out of sync visually.
- Animations were paused depending on whether there were any consumers,
this is different to the behavior in other browsers (where they
continue regardless of whether there are any consumers).
- It was an overgeneralization of how animations need to work - only
`AnimatedBitmapDecodedImageData` works with an indexed frame model,
with animated SVGs (although not yet implemented) relying on their
internal event loop to be driven forward.
Given the above the new approach implemented in this commit is:
- The API for `DecodedImageData` is animation system agnostic, only
exposing `default_frame`, `current_frame`, and `restart_animation`
methods not reliant on providing a specific frame index.
- `AnimatedBitmapDecodedImageData` owns its own timer, loop count,
etc. The animation starts when the first consumer registers and ends
when the document is hidden or becomes inactive (or completes in the
case of finite animations).
- Consumers are invalidated by `AnimatedBitmapDecodedImageData` when
required.
Tests have been added for:
- Animations being paused when the document becomes inactive and
restarted when it becomes active again.
- Frame timings being synchronized across consumers.
- Restarts triggered by `HTMLImageElement` applying to all consumers.
- Processing ending once a non-infinite animation plays to completion.
The tests to ensure animations are cancelled when consumers are removed
(e.g. `animated-background-image-timer-stops-when-hidden.html`) have
been updated to assert the inverse since animation state is now per
resource not per consumer.
2026-06-15 19:56:00 -03:00
|
|
|
|
|
|
|
|
image_data->on_client_registered();
|
2026-06-14 07:04:42 -03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void DecodedImageData::Client::unregister_with_decoded_image_data_if_needed()
|
|
|
|
|
{
|
|
|
|
|
auto const& image_data = decoded_image_data();
|
|
|
|
|
|
|
|
|
|
if (!image_data)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
image_data->m_clients.remove(this);
|
|
|
|
|
}
|
|
|
|
|
|
2023-05-20 11:11:36 -03:00
|
|
|
DecodedImageData::DecodedImageData() = default;
|
2023-05-10 14:36:43 -03:00
|
|
|
|
|
|
|
|
DecodedImageData::~DecodedImageData() = default;
|
|
|
|
|
|
2026-06-14 07:04:42 -03:00
|
|
|
void DecodedImageData::notify_clients_did_update()
|
|
|
|
|
{
|
|
|
|
|
for (auto* client : m_clients)
|
|
|
|
|
client->decoded_image_data_did_update();
|
|
|
|
|
}
|
|
|
|
|
|
2023-05-10 14:36:43 -03:00
|
|
|
}
|