Previously, when looking for the labeled control of a label element, we
were only checking its child elements. The specification says we should
check all elements in the same tree as the label element.
As MMIO is placed at fixed physical addressed, and does not need to be
backed by real RAM physical pages, there's no need to use PhysicalPage
instances to track their pages.
This results in slightly reduced allocations, but more importantly
makes MMIO addresses which end up after the normal RAM ranges work,
like 64-bit PCI BARs usually are.
* Matches how the loader is organized
* `compress_VP8L_image_data()` will grow longer when we add actual
compression
* Maybe someone wants to write a lossy compressor one day
No behavior change.
This code path now also compresses to memory once, and then writes to
the output stream.
Since the animation writer has a SeekableStream, it could compress to
the stream directly and fix up offsets later. That's more complicated
though, and keeping the animated and non-animated code paths similar
seems nice. And the drawback is just temporary higher memory use, and
the used memory is smaller than the memory needed by the input bitmap.
Before, we used to compress the image data to memory, then make another
copy to memory, and then write to the output stream.
Now, we compress to memory once and then write to the output stream.
No behavior change.
It is now possible to pass an optional `ImageDataSettings` object to
the `CanvasImageData.createImageData()` and
`CanvasImageData.getImageData()` methods.
We'll want to explicitly load fonts from FontFace and other Web APIs
in the future. A future refactor should also move this completely away
from StyleComputer and call it something like 'FontCache'.
We're now getting errors on CI due to gcc-13 being missing. We can
probably be smarter about what packages we install, depending on the
workflow being run. But let's first unblock CI.
The error we get is a bit strange and inconsistent. Some CI runners seem
to already have gcc-13 installed. Others don't and can't find the gcc-13
package without the test Ubuntu toolchain PPA.
With this only `ContinuePendingUnwind` needs to dynamically check if a
scheduled return needs to go through a `finally` block, making the
interpreter loop a bit nicer
This actually allows us to re-introduce the ldd utility as a symlink to
our dynamic loader, so now ldd behaves exactly like on Linux - it will
load all dynamic dependencies for an ELF exectuable.
This has the advantage that running ldd on an ELF executable will
provide an exact preview of how the order in which the dynamic loader
loads the executable and its dependencies.
As a preparation to introducing ldd as a symlink to /usr/lib/Loader.so
we rename the ldd utility to be elfdeps, at its sole purpose is to list
ELF object dependencies, and not how the dynamic loader loads them.
This is useful for testing ELF binaries that expose other functionalites
based on the argv0 string (BuggieBox, for example, does it to determine
which utility to run).
