Reduces the time to run
Build/lagom/image ~/src/libwebp/webp_js/test_webp_wasm.webp -o tmp.png
from 0.5s to 0.25s.
Before, 60% of the time was spent decoding webp and 40% writing png.
Now, 16% of the time was spent decoding webp and 84% writing png.
That means png writing takes 0.2s, and webp decoding time went from
0.3s to 0.05s.
A template expression without explicit return type deduces its return
type as if for a function whose return type is declared auto. That
does deduce return-by-value, while `decltype(auto)` would deduce
return-by-reference. Explictly saying `decltype(auto)` would work
too, but writing out the type is maybe easier to understand.
No behavior change other than being much faster.
The previous attempt was in commit e5e9d3b877, where I thought
max_symbol describes how many code lengths should be read.
But it looks like it instead describes how many code length input
symbols should be read. (The two aren't the same since one code length
input symbol can produce several code lengths.)
I still agree with the commit description of e5e9d3b877 that the spec
isn't very clear on this :)
This time I've found a file that sets max_symbol and with this change
here, that file decodes correctly. (It's Qpalette.webp, which I'm about
to add as a test case.)
This ports MouseEvent, UIEvent, WheelEvent, and Event to new String.
They all had a dependency to T::create() in
WebDriverConnection::fire_an_event() and therefore had to be ported in
the same commit.
Webp lossless can have up to 2328 symbols. This code assumed the deflate
max of 288, leading to crashes for webp lossless files using more than
288 symbols (such as Tests/LibGfx/test-inputs/simple-vp8l.webp).
Nothing writes webp files at this point, so the m_bit_codes and
m_bit_code_lengths arrays aren't ever used in practice with more than
288 entries.
WebP lossless differs from deflate in how it handles 1-element codes.
Deflate consumes one bit from the bitstream to produce the element,
while webp lossless consumes 0 bits. Add a wrapper class to handle
this case.
It's not totally clear to me when all of these states are supposed to be
set. For example, nothing in the HTMLMediaElement spec says to "set the
readyState attribute to HAVE_ENOUGH_DATA". However, this will at least
advance the readyState to HAVE_METADATA, which is needed for other
useful attributes for debugging.
The spec for loading a media element is quite huge. This implements just
enough to parse the attribute, fetch the corresponding media object, and
decode the media object (if it is a video). While doing so, this also
implements most network state tracking and firing DOM events that may be
observed via JavaScript.
Some elements, like HTMLMediaElement, must have a unique task sources
for every instance of that element that is created. Support this with a
simple wrapper around IDAllocator.
This copies the video data from the Matroska document into the Track
structure that outside users have access to. Because Track can actually
represent other media types, this is set up such that the Track can hold
metadata for those other types when they are needed.
This is needed for LibWeb's HTMLMediaElement implementation.
Grid and flex containers have their own rules for abspos items, so we
shouldn't try to be clever and put them in the "current" anonymous
wrapper block. That behavior is primarily for the benefit of block &
inline layout.
The `static` here meant we always kept the alphabet sizes of the
first image we happened to load -- and a single webp lossless image
can store several helper images used during decoding.
Usually, the helper images wouldn't use a color cache but the main
image would, but the main image would then use the first entry from
the helper images due to the `static`, which led us to not decoding
the codes for the color cache symbols.
When calculating the intrinsic width of a block-level box, we now ignore
the preferred width entirely, and not just when the preferred width
should be treated as auto.
The condition for this was both confused and wrong, as it looked at the
available width around the box, but didn't check for a width constraint
on the box itself.
Just because the available width has an intrinsic sizing constraint
doesn't mean that the box is undergoing intrinsic sizing. It could also
be the box's containing block!
No need to store them in `i32`, the JPEG norm specifies that they are
not bigger than 16 bits for extended JPEGs. So, in this patch, we
replace `i32` with `i16`. It almost divides memory usage by two :^)
