Stop worrying about tiny OOMs. Work towards #20449.
While going through these, I also changed the function signature in many
places where returning ThrowCompletionOr<T> is no longer necessary.
is_scroll_container() returns true for "overflow: hidden" which allows
programmable scrolling while is_scrollable() returns true only for
"overflow: scroll" and "overflow: auto" which allow scrolling only by
user interactions.
The `clip_shrink` optimization in `paint_background()` now also
correctly uses DevicePixels, instead of reducing a DevicePixel rect by
a CSSPixels amount.
This change makes tree builder omit elements with "display: contents"
from the layout tree during construction. Their child elements are
instead directly appended to the parent element in layout tree.
The main missing features are rootMargin, proper nested browsing
context support and content clip/clip-path support.
This makes images appear on some sites, such as YouTube and
howstuffworks.com.
Although DistinctNumeric, which is supposed to abstract the underlying
type, was used to represent CSSPixels, we have a whole bunch of places
in the layout code that assume CSSPixels::value() returns a
floating-point type. This assumption makes it difficult to replace the
underlying type in CSSPixels with a non-floating type.
To make it easier to transition CSSPixels to fixed-point math, one step
we can take is to prevent access to the underlying type using value()
and instead use explicit conversions with the to_float(), to_double(),
and to_int() methods.
Solves conflict in layout tree "type system" when elements <label> (or
<button>) can't have `display: table` because Box can't be
Layout::Label (or Layout::ButtonBox) and Layout::TableBox at the same
time.
This allows us to figure out where a specific CSS property comes from,
which is going to be used in a future commit to uniquely identify
running animations.
This fixes a plethora of rounding problems on many websites.
In the future, we may want to replace this with fixed-point arithmetic
(bug #18566) for performance (and consistency with other engines),
but in the meantime this makes the web look a bit better. :^)
There's a lot more things that could be converted to doubles, which
would reduce the amount of casting necessary in this patch.
We can do that incrementally, however.
Some of the live HTMLCollection only ever contain children of their root
node. When we know that's the case, we can avoid doing a full subtree
traversal of all descendants and only visit children.
This cuts the ECMA262 spec loading time by over 10 seconds. :^)
Before this, any style change that mutated a property we consider
"layout-affecting" would trigger a complete teardown and rebuild of the
layout tree.
This isn't actually necessary for the vast majority of CSS properties,
so this patch makes the invalidation a bit finer, and we now only
rebuild the layout tree when the CSS display property changes.
For other layout-affecting properties, we keep the old layout tree (if
we have one) and run the layout algorithms over that once again.
This is significantly faster, since we don't have to run all the CSS
selectors all over again.
The resolved property sets are stored with the element in a
per-pseudo-element array (same as for pseudo element layout nodes).
Longer term, we should stop storing this with elements entirely and make
it temporary state in StyleComputer somehow, so we don't waste memory
keeping all the resolved properties around.
This makes various gradients show up on https://shopify.com/ :^)
Layout will be identical for both of those values, so only a repaint is
necessary. If it changes to/from "collapse" however, we do need to
relayout. This means we can't simply use the "affects-layout" mechanism.
We have to write a little bit of custom code.
This makes Google Groups (and surely many other sites) significantly
more responsive by avoiding large amounts of layout work.
