| Age | Commit message (Collapse) | Author |
|---|
|
We now position inline-level boxes based on ascent and descent metrics
from the font in use. This makes our basic text layouts look a lot more
like those produced by other browsers. :^)
I've tried to match the terminology used by the CSS Inline Layout spec.
This will regress Acid2 a little bit, and probably various other sites,
but on the whole it's the direction we should be heading, so let's go.
|
|
|
|
This avoids a bunch of unnecessary work in Painter which not only took
time, but sometimes also led to alignment issues. draw_text_run() will
draw the text where we tell it, and that's it.
|
|
Preserve floating point precision and delay rounding until the last
moment when figuring out where to paint background layers. This fixes an
issue on Acid3 where a thin sliver of red was visible because the
background X position was incorrectly rounded by 1px.
|
|
By using enclosing_int_rect(), borders and backgrounds of boxes were
sometimes 1 pixel off, making things slightly larger than they should
be. Fix this by using to_rounded() instead of enclosing_int_rect().
There's definitely more of these type of issues lurking in the code,
and we'll get to them in time.
|
|
Relatively positioned boxes should not affect the *layout* of their
siblings. So instead of applying relative inset as a layout-time
translation on the box, we now perform the adjustment at the paintable
level instead.
This makes position:relative actually work as expected, and exposes some
new bugs we need to take care of for Acid2. :^)
|
|
This gives us consistent results with both bitmap and scalable fonts.
|
|
For layers that require indirect painting (due to opacity, transform,
etc.) we create a nested PaintContext. Until now, that PaintContext
was created fresh without transferring all the state from the parent
PaintContext.
|
|
Now it actually looks like a classic focus outline and not some
misplaced border :^)
|
|
Instead of using the absolute_rect(), use absolute_border_box_rect() -
at least for PaintableBox - and inflate it by 2px on each side.
This looks much nicer for text input elements, especially when they have
padding, which would be applied outside the focus rect previously.
|
|
Rather than dividing the rect width and high by the border lengths,
this change multiples those lengths by the reciprocal of the width
and height because this is a faster operation. When mousing around on
the html spec website, the profile showed that inline painting
went from ~15% to ~3%
|
|
This fixes the placement of several background images on Acid2, most
notably the background of the eyes and the red rectangle near the bottom
of the head.
|
|
This makes the shadow line-up correctly on Acid3. :^)
|
|
Normally, paintable coordinates are relative to the nearest containing
block, but in the SVG case, since <svg> doesn't form a containing block,
we have to specialize the computation of SVGPaintable::absolute_rect().
|
|
We don't yet take the spread-distance parameter into account, since we
don't have a way to "inflate" the text shadow.
Also, I'm not sure if we need to inflate the shadow slightly anyway.
Blurred shadows of our pixel fonts seem very faint. Part of this is
that a blur of < 3px does nothing, see #13231, but even so we might
want to inflate it a little.
|
|
The `text-shadow` property is almost identical to `box-shadow`:
> Values are interpreted as for box-shadow [CSS-BACKGROUNDS-3].
> (But note that the inset keyword are not allowed.)
So, let's use the same data structures and parsing code for both. :^)
|
|
This replaces the usage of `rounded_int_rect`, whose name did not
accurately reflect the rounding operation happening. For example, the
position of the rect was not rounded but floored, and the size was
pulled through `roundf` before casting to `int` which could result in
inadvertent flooring if the resulting floating point could not exactly
represent the rounded value.
|
|
|
|
We don't have transform-box yet, so this applies to the border-box
for now.
This also makes us pass a couple Web Platform Tests as well :^)
For example:
https://wpt.live/css/css-transforms/css3-transform-scale-002.html
|
|
|
|
|
|
|
|
We already walk the entire paint tree within each stacking context in
the main hit testing function (StackingContext::hit_test()), so there's
no need for each individual paintable to walk its own children again.
By not doing that, we remove a source of O(n^2) traversal which made hit
testing on deeply nested web pages unbearably slow.
|
|
|
|
This is a convenience accessor to avoid having to say this everywhere:
result.paintable->layout_node().dom_node()
Instead, you can now do:
result.dom_node()
|
|
Using "HitTestResult with null paintable" as a way to signal misses was
unnecessarily confusing. Let's use Optional instead. :^)
|
|
There's no actual need to build the stacking context tree before
performing layout. Instead, make it lazy and build the tree when it's
actually needed for something.
This avoids a bunch of work in situations where multiple synchronous
layouts are forced (typically by JavaScript) without painting or hit
testing taking place in between.
It also opens up for style invalidations that only target the stacking
context tree.
|
|
Since paintables have a default content size of 0x0, we were neglecting
to notify the corresponding layout node about size changes, if the used
content size came out to 0x0.
This fixes an issue where resizing an iframe to 0x0 didn't take effect.
|
|
For stacking contexts that have opacity between 0 and 1, and also
contexts with a 2D transform, we first paint them into a temporary layer
buffer. Then we blend that buffer with the contents in one go.
Before this patch, we were only drawing the content box of the stacking
context into this layer buffer, which led to padding and borders missing
from elements painted this way.
|
|
This makes SVG-in-HTML behave quite a bit better by following general
replaced layout rules. It also turns <svg> elements into inline-level
boxes instead of block-level boxes.
|
|
For paintables that don't know how to hit test themselves, let's just
return nothing instead of crashing.
|
|
This now also takes a FloatPoint instead of an IntPoint to avoid
excessive rounding when multiple transforms apply on top of each other.
|
|
Since there is currently no easy way to handle rotations and skews
with LibGfx this only implements translation and scaling by first
constructing a general 4x4 transformation matrix like outlined in
the css-transforms-1 specification. This is then downgraded to a
Gfx::AffineTransform in order to transform the destination rectangle
used with draw_scaled_bitmap()
While rotation would be nice this already looks pretty good :^)
|
|
No need to call the expensive establishes_stacking_context() here, as
we've already built the stacking context tree and can simply test for
the presence of existing stacking contexts.
|
|
All the other painting code has moved to paintables already.
|
|
By the time we're painting, we've already built the stacking context
tree. So instead of asking if a box establishes a stacking context, we
can ask if its paintable *has* a stacking context.
This was taking up ~6% of the profile when mousing around on the HTML
specification. With this change, it disappears completely. :^)
|
|
This commit is messy due to the Paintable and Layout classes being
tangled together.
The RadioButton, CheckBox and ButtonBox classes are now subclasses of
FormAssociatedLabelableNode. This subclass separates these layout nodes
from LabelableNode, which is also the superclass of non-form associated
labelable nodes (Progress).
ButtonPaintable, CheckBoxPaintable and RadioButtonPaintable no longer
call events on DOM nodes directly from their mouse event handlers;
instead, all the functionality is now directly in EventHandler, which
dispatches the related events. handle_mousedown and related methods
return a bool indicating whether the event handling should proceed.
Paintable classes can now return an alternative DOM::Node which should
be the target of the mouse event. Labels use this to indicate that the
labeled control should be the target of the mouse events.
HTMLInputElement put its activation behavior on run_activation_behavior,
which wasn't actually called anywhere and had to be manually called by
other places. We now use activation_behavior which is used by
EventDispatcher.
This commit also brings HTMLInputElement closer to spec by removing the
did_foo functions that did ad-hoc event dispatching and unifies the
behavior under run_input_activation_behavior.
|
|
Instead of calling quick_sort() every time a StackingContext child
is added to a parent, we now do a single pass of sorting work after the
full StackingContext tree has been built.
Before this change, the quick_sort() was ~13.5% of the profile while
hovering links on GitHub in the Browser. After the change, it's down to
~0.6%. Pretty good! :^)
|
|
This wasn't worth the headache of trying to make SVG boxes work together
with BFC right now. Let's just make it a block container once again, and
have its corresponding SVGPaintable inherit from PaintableWithLines.
We'll have to revisit this as SVG support improves.
|
|
When doing viewbox transforms, elliptical always had large arc and
sweep flag set to false. Preserve these flags so they can be set
correctly when applying viewbox transformations.
|
|
The absolute rect of a paintable is somewhat expensive to compute. This
is because all coordinates are relative to the nearest containing block,
so we have to traverse the containing block chain and apply each offset
to get the final rect.
Paintables will never move between containing blocks, nor will their
absolute rect change. If anything changes, we'll simpl make a new
paintable and replace the old one.
Take advantage of this by caching the containing block and absolute rect
after first access.
|
|
|
|
|
|
Everything related to hit testing is better off using the painting tree.
The thing being mousemoved over is a paintable, so let's hand that out
directly instead of the corresponding layout node.
|
|
Input events have nothing to do with layout, so let's not send them to
layout nodes.
The job of Paintable starts to become clear. It represents a paintable
item that can be rendered into the viewport, which means it can also
be targeted by the mouse cursor.
|
|
This will allow us to use a protective NonnullRefPtr to keep paintables
alive while running arbitrary JavaScript in response to events.
|
|
This is prep work for moving event handling over to the painting tree.
|
|
This patch adds InlinePaintable which corresponds to Layout::InlineNode.
|
|
To prepare for paintable inline content, we take the basic painting
functionality and hoist it into a base class.
|
|
Let's move away from accessing the m_layout_box member directly.
|
