Instead of everyone overriding save_to() and set_property() and doing
a pretty asymmetric job of implementing the various properties, let's
add a bit of structure here.
Object properties are now represented by a Core::Property. Properties
are registered with a getter and setter (optional) in constructors.
I've added some convenience macros for creating and registering
properties, but this does still feel a bit bulky. We'll have to
iterate on this and see where it goes.
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 makes images have an implicit zero intrinsic size before
they have either loaded or failed to load. This is tracked by the
ImageLoader object.
This fixes a long-standing issue with images occupying empty 150x150
rectangles of space.
This function did a const_cast internally which made the call side look
"safe". This method is removed completely and call sites are replaced
with ByteBuffer::wrap(const_cast<void*>(data), size) which makes the
behaviour obvious.
LibWeb keeps growing and the Web namespace is filling up fast.
Let's put DOM stuff into Web::DOM, just like we already started doing
with SVG stuff in Web::SVG.
This should enable to destinguish between IFrame, Reload and Navigation
motivated loads in order to call the appropriate hooks.
This change is motivated as loading the IFrame test page causes the
IFrame url to be added to the history and shows up as the current
browser location bar.
We still use a Gfx::ImageDecoder for GIF images, but there's no need
for the ImageLoader object to have its own pointer to it. Just grab
the ImageDecoder from the ImageResource when needed.
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.
The only remaining client of the old parser is the fragment parser used
by the Element.innerHTML setter. We'll need to implement a bit more
stuff in the new parser before we can switch that over.
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.
Since more DOM nodes are going to want to load images (<object>, ...)
this patch splits out the image loading logic into an ImageLoader class
and then HTMLImageElement simply has an ImageLoader.
LayoutImage is then given a const ImageLoader& at construction and can
then provide layout and rendering for many kinds of DOM nodes.
Clients now receive HTTP status codes like 200, 404, etc.
Note that a 404 with content is still considered a "successful"
download from ProtocolServer's perspective. It's up to the client
to interpret the status code.
I'm not sure if this is the best API, but it'll work for now.
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.
