This ports XHR's fire_progress_event() and request_error_steps() to new
FlyString.
Signature of fire_progress_event() parameter event_name was changed
from 'String const&' to 'FlyString const&'.
Prefix code decoding seems to work fairly well and produces a ton of
log output with `#define WEBP_DEBUG 1`, so remove the log lines.
(If needed it's always possible to just locally revert this commit.)
No behavior change, since WEBP_DEBUG isn't usually defined.
When we had 32 bit support in the OS kernel and userland, the very bare
minimum CPU we supported was Pentium 3, but now the CPU is just required
to support x86-64 long mode to be supported, so the exact model is not
very important.
I chose the QEMU64 virtual CPU model, because the whole concept of the
QEMU ISA-PC machine is that it checks how the kernel handles arbitrarily
old hardware setup.
The definitions were being defined already by `BootInfo.h` and that was
being included here via transitive includes. The extern definitions of
the variables do not have the `READONLY_AFTER_INIT` attribute in
`BootInfo.h`. This causes conflicting definitions of the same variable.
The `READONLY_AFTER_INIT` specifier is not needed for extern variables
as it only effects their linkage, not their actual use, so just use the
versions in `BootInfo.h` instead of re-declaring.
Every other function there returning a RenderRequest has one, so might
as well.
Don't add it to check_and_remove_full_rows(), because it's only used
inside other functions returning a RenderRequest, when it's already
clear a render will happen.
WebP lossless files that use a color indexing transform with <= 16
colors use pixel bundling to pack 2, 4, or 8 pixels into a single pixel.
If the image's width doesn't happen to be an exact multiple of the
bundling factor, we need to:
1. Use ceil_div() instead of just dividing the width by the bundling
factor
2. Remember the original width and use it instead of computing
reduced width times bundling factor
This does these changes, and adds a simple test for it -- it at least
checks that the decoded images have the right size.
(I created these images myself in Photoshop, and used the same
technique as for Tests/LibGfx/test-inputs/catdog-alert-*.webp
to create images with a certain number of colors.)
If the video element has a 'controls' attribute, we now paint some basic
video controls over the video element. If no frame has been decoded yet,
we paint a play button on the center of the element.
If a frame has been decoded, we paint that frame and paint a control bar
on the bottom of the frame. This control bar currently only contains a
play/pause button, depending on the video's playback state. We will only
paint the control bar if the video is paused or hovered.
Note that the default value of the attribute is true. We were previously
autoplaying videos as soon as they loaded - this will prevent that from
happening until the paused attribute is set to false.
For the test files, I opened Base/res/icons/catdog/alert.png in Adobe
Photoshop 2023, used Image->Mode->Index Color...->
Palette: Local (Perceptive) to reduce the number of colors to 13, 8, and
3 with transparency, and 2 without transparency, then converted it back
to Image->Mode->RGB Color (else it can't be saved as webp), then
File->Save a Copy... to save a WebP (mode lossless) for every palette
size.
See the lengthy comment added in this commit for details.
With this, the webp lossless decoder is feature complete :^)
(...except for bug fixes and performance improvements, as always.)
...in addition to modifying in-place. This is needed for bitpacking
support for the color indexing transform (and it could also be used
to make the color indexing transform return an indexed bitmap, which
is something we could do if that's the last transform that's applied).
No behavior change.
