| Age | Commit message (Collapse) | Author |
|---|
|
For inline-blocks and inline replaced elements, we previously fell into
a code path that tried to find a corresponding line box fragment to
invalidate. However, we don't need to do any of that, all we need to do
is get the absolute rect from our paintable, and invalidate that.
This makes CRC2D invalidations happen immediately instead of as a side
effect of some other invalidation.
|
|
I want to use this function in inline layout, where we're not just
dealing with boxes.
|
|
|
|
|
|
|
|
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.
|
|
This will allow us to use a protective NonnullRefPtr to keep paintables
alive while running arbitrary JavaScript in response to events.
|
|
To prepare for paintable inline content, we take the basic painting
functionality and hoist it into a base class.
|
|
|
|
This patch adds a bunch of Paintable subclasses, each corresponding to
the Layout::Node subclasses that had a paint() override. All painting
logic is moved from layout nodes into their corresponding paintables.
Paintables are now created by asking a Layout::Box to produce one:
static NonnullOwnPtr<Paintable> Layout::Box::create_paintable()
Note that inline nodes still have their painting logic. Since they
are not boxes, and all paintables have a corresponding box, we'll need
to come up with some other solution for them.
|
|
Calling this "Box" made it very confusing to look at code that used both
Layout::Box and Painting::Box. Let's try calling it Paintable instead.
|
|
BlockContainer paint boxes are the only ones that have line boxes
associated, so let's not waste memory on line boxes in all the other
types of boxes.
This also adds Layout::Box::paint_box() and the more tightly typed
Layout::BlockContainer::paint_box() to get at the paint box from the
corresponding layout box.
|
|
Stacking contexts have nothing to do with layout and everything with
painting, so let's keep them in Painting::Box.
|
|
|
|
The "paintable" state in Layout::Box was actually not safe to access
until after layout had been performed.
As a first step towards making this harder to mess up accidentally,
this patch moves painting information from Layout::Box to a new class:
Painting::Box. Every layout can have a corresponding paint box, and
it holds the final used metrics determined by layout.
The paint box is created and populated by FormattingState::commit().
I've also added DOM::Node::paint_box() as a convenient way to access
the paint box (if available) of a given DOM node.
Going forward, I believe this will allow us to better separate data
that belongs to layout vs painting, and also open up opportunities
for naturally invalidating caches in the paint box (since it's
reconstituted by every layout.)
|
|
We now perform hit testing in reverse paint order as described in CSS2's
section about the z-index property.
|
|
Layout should not change any properties of a box until the moment a
FormattingState is committed.
|
|
Using WeakPtr to remember which LineBoxFragment owns which Box was
imposing some annoying constraints on the layout code. Importantly, it
was forcing us to heap-allocate fragments, which makes it much harder to
clone a FormattingState.
This patch replaces the WeakPtr with a coordinate system instead.
Fragments are referred to by their line box index + fragment index
within the line box.
|
|
Instead of just the outline, fill them with some semi-transparent color.
Also add tag name, ID, classes and coordinates to the little tooltip.
Finally, use the border box instead of the context box for metrics,
same as other browsers.
|
|
This adds a small tooltip in the browser showing the size of the
element that currently selected in the inspector view. This allows
for easier debugging since you dont have to dump the layout tree :^).
|
|
Now that calc() is also resolved in to_px(), code in the form
`foo.resolved(bar).to_px(bar)` can be simplified to `foo.to_px(bar)`.
|
|
Nobody makes undefined Lengths now, (although actually removing
Undefined will come in a later commit) so we can remove this parameter,
and `resolved_or_auto()`/`resolved_or_zero()`.
|
|
- padded_rect() -> absolute_padding_box_rect()
- bordered_rect() -> absolute_border_box_rect()
|
|
We also pass whether the shadow goes inside or outside the element. Only
outer shadows are rendered currently, and inner ones may want to be
handled separately from them, as they will never interfere with each
other.
|
|
Because why not? :^)
|
|
This property represents the CSS content size, so let's reduce ambiguity
by using the spec terminology.
We also bring a bunch of related functions along for the ride.
|
|
Despite looking like it was still needed, it was only used for passing
to other calls to Length::resolved() recursively. This makes the
various `foo.resolved().resolved()` calls a lot less awkward.
(Though, still quite awkward.)
I think we'd need to separate calculated lengths out to properly tidy
these calls up, but one yak at a time. :^)
|
|
Browsing contexts are defined by the HTML specification, so let's move
them into the HTML directory. :^)
|
|
We now pass in the Layout Node so that we can read the BoxModelMetrics.
Renamed a couple of variables too for clarity.
|
|
|
|
Instead of storing these as individual `background-foo` properties, we
combine them together into layers, since that is how they will be
painted. It also makes it more convenient to pass them around.
|
|
While right now this doesn't save much complexity, it will do once we
care about multiple background layers per node. Then, having a single
repeat value per layer will simplify things.
It also means we can remove the pseudo-property concept entirely! :^)
|
|
This is a very limited implementation of overflow:hidden, but since it's
easy to cover this common scenario, let's do it.
|
|
This was a hack to percentages within tables relative to the nearest
table-row ancestor instead of the nearest table container.
That didn't actually make sense, so this patch simply removes the hack
in favor of containing_block()->width().
|
|
This makes everything within the stacking context stick show up in the
correct position.
|
|
Per the spec, only a BlockContainer" can have line boxes, so let's not
clutter up every Layout::Box with line boxes.
This also allows us to establish an invariant that BFC and IFC always
operate on a Layout::BlockContainer.
Note that if BlockContainer has all block-level children, its line boxes
are not used for anything. They are only used in the all inline-level
children scenario.
|
|
There's a subtle difference here. A "block box" in the spec is a
block-level box, while a "block container" is a box whose children are
either all inline-level boxes in an IFC, or all block-level boxes
participating in a BFC.
Notably, an "inline-block" box is a "block container" but not a "block
box" since it is itself inline-level.
|
|
The logic here is needed by InlineNode too. Moving it into a
`paint_all_borders()` function makes it available to them both, as well
as anyone else who wants it. :^)
|
|
This makes the code accessible to things that aren't a Box, such as
InlineNode.
|
|
This makes the code accessible to things that aren't a Box, such as
InlineNode.
|
|
This is going to be needed by InlineNodes too!
`BorderPainting.{h,cpp}` might not be the best place for it, but it
works for now.
|
|
We were computing the padded rect of the box during every paint phase,
despite only needing it in the Overlay phase.
Since this is an expensive call, let's take care not to make it
unnecessarily.
|
|
We're still limited by Gfx::Painter here, but we can at least do most
of the LibWeb things in floating-point math.
|
|
The previous VERIFY_NOT_REACHED() could be reached when there were equal
coodinates. This could be the case for a small radius which lead to
rounding making the two coordinates equal.
|
|
A slight loss in graphical fidelity is better than not rendering the
page at all.
|
|
Computing the absolute rect of a box requires walking the chain of
containing blocks and apply any offsets encountered. This can be slow in
deeply nested box trees, so let's at least avoid doing it multiple times
when once is enough.
|
|
In some situations, a layout box should not participate in the standard
layout process, for example when set to `position: absolute`.
|
|
The "Box" suffix added nothing here.
|
|
|
|
Now the box-shadow-rendering is done by using the new
Gfx::FastBoxBlurFilter. :^)
|
