This now copies the area under the destination to a new bitmap, that
is then scaled to the size of the source. The element is then painted
into that bitmap, which is then scaled and painted back to
the destination. This is done as many effects such as shadows, border
radii, filters, etc require being able to read pixels from the painter.
This does work (and is not that noticeable in many cases), but it does
mean there may be a few scaling artifacts in the background
around transformed elements. Though that was already the case before
anyway for the elements (since it is just a bitmap scale).
What we really want is to (where possible) just scale the paintable
and its descendants, then paint things normally, which would give
much nicer results (but is much more tricky to achieve).
This also now makes it so only a bitmap of the size of the paintable is
copied/created, rather than the whole page.
This method returns the total area this element will paint to.
Currently, this just means accounting for box-shadows, though
there are likely more effects that need to be accounted for here.
This patch changes the *computed* representation of the following CSS
properties to use CSS::Size:
- width, min-width, max-width
- height, min-height, max-height
A few things had to change in order for things to keep working,
but I tried to keep the diff to a minimum.
The main trouble was that `min-width` and `max-width` can't actually be
`auto`, but they *can* be `none`. We previously treated `auto` as a
valid value (and it behaved mostly like `none`).
Until now, we've been using CSS::LengthPercentage, sometimes wrapped in
Optional, to represent CSS sizes.
This meant we could not support modern values like `min-content`,
`max-content`, `fit-content(<length>)`. We were also conflating `none`
and `auto` which made the `min-*` and `max-*` properties confusing.
The new CSS::Size class covers all possible size values as individual
substates. It'll be quite a bit of work to make all layout code aware of
the additional features, this patch merely makes the new type available.
We don't need to notify the web views that some deeply nested iframe
has started loading a new URL (and we don't want it showing up in the
browser location bar either!)
Two issues made this class unusable on other platforms:
- Hardcoded /res paths to icons
- It required a GUI::TreeView for palette access
This patch simply patches out those features on non-Serenity systemsf
for now.
When mousing over twitter, 17% of time was spent computing stacking
context transform origins. Since this never changes after the stacking
context is created, we can cache it and avoid all that work.
Let's stop putting generic types and AOs from the Web IDL spec into
the Bindings namespace and directory in LibWeb, and instead follow our
usual naming rules of 'directory = namespace = spec name'. The IDL
namespace is already used by LibIDL, so Web::WebIDL seems like a good
choice.
These are from the HTML spec and therefore belong in the HTML/ directory
in LibWeb. Bindings/ has become a bit of a dumping ground, so this is a
first step towards cleaning that up.
63c727a was meant to stop clipping absolutely positioned descendants,
but used `is_positioned()` rather than `is_absolutely_positioned()`,
which meant it disabled clipping in many more cases that it should
have.
This fixes an issue where, when looping over the components of a
composite glyph, we used to mutate the affine transformation of the
glyph itself when computing the transformations of its components.
(AffineTransform::multiply() is non-const).
In case of possible framebuffer mapping overflow, just fallback to the
safe mode-setting of the DisplayConnector, because in that state we know
for sure that we can map a usable framebuffer (otherwise it is a bug in
the Kernel, and not WindowServer).
This value will be used later on by WindowServer to reject resolutions
that will request a mapping that will overflow the hardware framebuffer
max length.
We simply don't need that field anymore, as it was used when one
FramebufferDevice could contain multiple framebuffers within it, each
for a connected screen head.
This ends up having a big impact on performance, as we now correctly
treat a used flex-basis of `content` as `max-content` which means
we can use cacheable intrinsic sizes for flex items in the majority
of cases.
This was used by FFC to estimate the height of flex items after
performing layout inside them.
Now that we have automatic_content_height(), we no longer need this
awkward API and we can fold it into BFC's own height calculation.
Previously, this would overflow when both length and offset were
zero, leading to an OOB index into es_array_buffer. This would lead to
a crash on a few MDN pages.
