This patch adds handling of the 'object-fit' CSS property to the
painting of HTML Image Elements.
This is achieved by first calculating the rect which the image would
need if it were to fully expand into open space and then adequately
cropping it to fit into the image's box.
scale-down is not supported for now.
Otherwise, in a simple page such as:
<video src=...>
<audio src=...>
The video's clip rect would "leak" to the AudioPaintable, preventing the
audio controls from rendering at all.
Not a huge deal because the base MediaPaintable class goes very out of
its way to paint within the confines of its own box, but just to be
safe, this was missed when adding the AudioPaintable class.
The `clip_shrink` optimization in `paint_background()` now also
correctly uses DevicePixels, instead of reducing a DevicePixel rect by
a CSSPixels amount.
When joined border width is zero width, then the midpoint
of the joined corner is no longer need to be computed
anymore. Just set the mid point to be the endpoint of the
corner.
Fixes broken border-radius painting because of lost precision while
converting back and forth between double and CSSPixels.
Fixed example:
```html
<style>
div {
border-radius: 9999px;
background: orange;
padding: 10px;
}
</style><div>huh</div>
```
Using fixed-point saturated arithmetics for CSSPixels allows to avoid
accumulating floating-point errors.
This implementation is not complete yet: currently saturated
arithmetics implemented only for addition. But it is enough to not
regress any of layout tests we have :)
See https://github.com/SerenityOS/serenity/issues/18566
The refactor of the border painting mainly to handle:
1. Single border with minor border radius.
2. Different border widths and border colors joined situations.
This refactor only apply to solid border.
The main differece is to use Path.fill to paint each border,
not fill_rect anymore. There's a special case need to consider.
The Path.fill will leave shared edge blank between two borders.
To handle this, we decide to combine the borders with same color
to paint together.
There are two parts to this fix:
- First, StyleProperties::transformations() would previously omit calc()
values entirely when returning the list of transformations. This was
very confusing to StackingContext which then tried to index into the
list based on faulty assumptions. Fix this by emitting calc values.
- Second, StackingContext::get_transformation_matrix() now always calls
resolve() on length-percentages. This takes care of actually resolving
calc() values. If no reference value for percentages is provided, we
default to 0px.
This stops LibWeb from asserting on websites with calc() in transform
values, such as https://qt.io/ :^)
Since we deliberately skip positioned elements in paint_descendants(),
we have to make sure we actually paint them in the subsequent
paint_internal() pass.
Before this change, we were only painting positioned elements whose
paintable was a PaintableBox, neglecting inline-level relpos elements.
Defer conversion to device pixels until we need to paint. This
helps borders of cells with different spans align, since rounding early
makes addition non-associative.
This finally fixes the issue where stacking contexts that have either a
transform or opacity != 1 would clip their descendants to the root of
the stacking context.
Importantly, we now only consider overflow from descendants with
explicltly visible overflow, and only from descendants that have the
measured box as their containing block.
Also, we now measure scrollable overflow for all boxes, not just scroll
containers. This will allow us to fix a long-standing paint problem in
the next commit.
Follow the specification in making the borders centered on the grid
lines. This avoids visual bugs due to double-rendering of borders on
either side of an edge and paves the way for a full implementation of
the harmonization algorithm for collapsed borders.
Currently, this still lacks complete handling of row and column spans.
Also, the box model for cells still considers the full width of the
internal borders instead of just half, as the specification requires.
Some additional handling of rounding issues will be needed to avoid very
subtle visual bugs.
Despite these limitations, this improves the appearance of all the
tables with collapsed borders I've tried while limiting the amount of
change to something reasonable.
Move painting of cell borders to a separated function since doing it
correctly has to consider the entire grid as a whole for the collapsed
borders case.
Feels nicer to click anywhere on the control box to toggle playback,
rather than needing to accurately click the playback button. Note this
does not affect other behavior-specific buttons; i.e. if the mute button
is pressed, we won't reach the playback toggle..
The SVGContext is a leftover from when SVG properties were more ad-hoc.
All properties are now (for better or worse) treated as CSS properties
(or handled elsewhere). This makes the SVGContext's fill/stroke
inheritance handling unnecessary.
Before this change, we only blurred the shadows which would've been
generated without blur. This meant that we didn't generate a shadow when
the offset was zero, even with blur. However, other browsers generate a
shadow when blur is set.
Instead, always generate a rectangular contour of sufficient thickness,
blur it if needed and blit it into the right position at the very end.
Thanks to the blur radius, we'll have a shadow even when the offset is
zero.
It's a little bit of a battle to fit all of the media controls in the
available width of the media element. We currently cram everything on
one horizontal line. We've made adjustments to be able to fit it all,
but the controls (in particular the media timeline) are rather squished.
This paints the timeline above the other media controls now. This
provides much more granular control over the playback position when
scrubbing, and makes it much more likely for the timeline to render at
all.
This implements the ability to drag the timeline and volume buttons on
UA-rendered media controls. The two behave a bit differently:
Volume is updated as the user drags the volume button. This isn't a very
expensive operation, so updating in real-time and hearing the volume
change feels nice.
The current time, on the other hand, is not committed until the user
releases the mouse button. Performing a seek every time we get a mouse-
move event is pretty laggy, especially for video. However, we still want
to render updates on the timeline itself (so the position of the button
and the timestamp update as you drag). To do so, we internally pause the
media and override the timestamp provided to the layout node.
In the future, we may be able to seek video periodically to provide some
visual feedback. For example, we can seek after every N seconds of
scrubbing, or when the user pauses scrubbing for a while.
Always use `would_be_fully_clipped_by_painter` to check if painting can
be skipped.
This allows to quickly find all the places where this check happens and
also removes incosistency that before we checked for intersection with
viewport rect in some places and for intersection with painter clip
rect in other places.
The idea here is to let us decide ahead of time what components to paint
depending on the size available. We currently paint each component left-
to-right, until we run out of room. This implicitly gives priority to
the left-most components.
We will soon paint volume controls on the right-side of the timeline.
Subjectively, they should have a higher priority than, say, the timeline
scrubbing bar (i.e. it's more important to be able to mute audio than to
seek). By computing these components before painting, we can more easily
allocate sections to the components in priority order, until the area
remaining has been depleted.
It can take some time to download / decode a media resource. During this
time, its duration is set to NaN. The media control box would then have
some odd rendering glitches as it tried to treat NaN as an actual time.
Once we do have a duration, we also must ensure the media control box is
updated.
