These changes are arbitrarily divided into multiple commits to make it
easier to find potentially introduced bugs with git bisect.Everything:
The modifications in this commit were automatically made using the
following command:
find . -name '*.cpp' -exec sed -i -E 's/dbg\(\) << ("[^"{]*");/dbgln\(\1\);/' {} \;
This patchset makes ProtocolServer stream the downloads to its client
(LibProtocol), and as such changes the download API; a possible
download lifecycle could be as such:
notation = client->server:'>', server->client:'<', pipe activity:'*'
```
> StartDownload(GET, url, headers, {})
< Response(0, fd 8)
* {data, 1024b}
< HeadersBecameAvailable(0, response_headers, 200)
< DownloadProgress(0, 4K, 1024)
* {data, 1024b}
* {data, 1024b}
< DownloadProgress(0, 4K, 2048)
* {data, 1024b}
< DownloadProgress(0, 4K, 1024)
< DownloadFinished(0, true, 4K)
```
Since managing the received file descriptor is a pain, LibProtocol
implements `Download::stream_into(OutputStream)`, which can be used to
stream the download into any given output stream (be it a file, or
memory, or writing stuff with a delay, etc.).
Also, as some of the users of this API require all the downloaded data
upfront, LibProtocol also implements `set_should_buffer_all_input()`,
which causes the download instance to buffer all the data until the
download is complete, and to call the `on_buffered_download_finish`
hook.
This reverts my previous commit in WebServer and fixes the whole issue
in a much better way. Instead of having the MIME type guesser take a
URL (which we don't actually have in the WebServer at that point),
just take a path as a StringView.
Also, make use of the case-insensitive StringView::ends_with() :^)
This enables a nice warning in case a function becomes dead code. Also, in the
case of {Event,Node}WrapperFactory.cpp, the corresponding header was forgotten.
This would cause an issue later when we enable -Wmissing-declarations.
Is my clang-format misconfigured? Why is the diff for NodeWrapperFactory.cpp
so large?
This patch adds support for JPEG decoding. The JPEG decoder is capable
of handling standard 2x1 horizontal, 2x1 vertical and quartered chroma
subsampling. The implemented Inverse DCT performs with a decent speed.
As of interchange formats, since we tend to ignore the metadata in APPn
markers, the decoder can handle any format compatible with JFIF, which
includes EXIFs and sometimes WebMs too. The decoder does not support
progressive JPEGs yet.
We now use the ImageDecoder service in LibWeb for everything except
GIF images (we'll have to deal with them later, ofc.)
This has a little bit of overhead but we should be able to optimize
it until it becomes negligible.
Adds an *almost fully featured BMP loader to process .bmp files.
Features:
- All header formats are supported
- Full RLE4/8/24 support
- Color scaling (e.g. distributing a 5-bit color throughout the 8-bit
color spectrum, so 5-bit white is still 0xffffff)
- Full BITMASK/ALPHABITMASK support
*Not included:
- 1D Huffman compression. Good luck actually finding a bmp in the wild
that uses this
- Use of any field in the V4/V5 header. Color spaces? Endpoints? No
thanks :)
This loader was tested with the images at
https://entropymine.com/jason/bmpsuite/bmpsuite/html/bmpsuite.html. This
loader correctly displays 81 out of the 90 total images (for reference,
firefox displays 64 correctly). Note that not rendering the images at
the bottom is counted as displaying correctly.
Also, if the request URL is a data: URL, use the MIME type from the URL
itself if available. This makes it possible to load arbitrary MIME type
data: URLs in the browser :^)
This was a confusing bug: ImageStyleValue loaded its image resource as
a Generic resource, while HTMLImageElement loaded as Image.
This patch fixes the issue and adds an assertion to verify that we only
share resources that have the same C++ client class type.
This patch adds ImageResource as a subclass of Resource. This new class
also keeps a Gfx::ImageDecoder so that we can share decoded bitmaps
between all clients of an image resource inside LibWeb.
With this, we now share both encoded and decoded data for images. :^)
I had to change how the purgeable-volatile flag is updated to keep the
volatile-images-outside-the-visible-viewport optimization working.
HTMLImageElement now inherits from ImageResourceClient (a subclass of
ResourceClient with additional image-specific stuff) and informs its
ImageResource about whether it's inside the viewport or outside.
This is pretty awesome! :^)
Notifying a Resource's clients may lead to arbitrary JS execution,
so we can't rely on the ResourceClient pointers remaining valid.
Use WeakPtr to avoid this problem.
This patch introduces a caching mechanism in ResourceLoader. It's keyed
on a LoadRequest object which is what you provide to load_resource()
when you want to load a resource.
We currently never prune the cache, so resources will stay in there
forever. This is obviously not gonna stay that way, but we're just
getting started here. :^)
This should drastically reduce the number of requests when loading
some sites (like Twitter) that reuse the same images over and over.
A Resource represents a resource that we're loading, have loaded or
will soon load. Basically, it's a downloadable resource that can be
shared by multiple clients.
A typical usecase is multiple <img> elements with the same src.
In a future patch, we will try to make sure that those <img> elements
get the same Resource if possible. This will reduce network usage,
memory usage, and CPU usage. :^)
For now, this first patch simply introduces the mechanism.
You get a Resource by calling ResourceLoader::load_resource().
To get notified about changes to a Resource's load status, you inherit
from ResourceClient and implement the callbacks you're interested in.
This patch turns HTMLImageElement into a ResourceClient.
