This is `counter(name, style?)` or `counters(name, link, style?)`. The
difference being, `counter()` matches only the nearest level (eg, "1"),
and `counters()` combines all the levels in the tree (eg, "3.4.1").
These control the state of CSS counters.
Parsing code for `reversed(counter-name)` is implemented, but disabled
for now until we are able to resolve values for those.
Before this change, "background-clip: text" was implemented by saving a
Vector<Gfx::Path> of all glyphs needed to paint a mask for the
background. The issue with this approach was that once glyphs were
extracted into vector paths, the glyph rasterization cache could no
longer be utilized.
With this change, all text required for mask painting is saved in a
nested display list and rasterized as a regular text.
With this change, instead of recording a display list item for each
instance of a repeated background, a new DrawRepeatedImmutableBitmap
type is used. This allows the painter to use optimized repeated image
painting and, when the GPU backend is used, avoid re-uploading the image
texture for each repetition.
Some screenshot tests are affected, but there are no visible
regressions.
https://null.com/games/chainstaff works a lof faster with this change.
We already have a FlyString of its value from parsing, and most users
also want a FlyString from it, so let's use that instead of converting
backwards and forwards.
The two users that did want a String are:
- Quotes, which make sense as FlyString instead, so I've converted that.
- Animation names, which should probably be FlyString too, but the code
currently also allows for other kinds of StyleValue, and I don't want
to dive into this right now to figure out if that's needed or not.
Apple Clang doesn't like this, rather than waiting for their version of
random-clang-commit-to-call-a-release to catch up with llvm trunk, just
work around the issue.
Fixes#186.
The values aren't that complex, so it doesn't make much sense to have a
dedicated generator for them. Parsing them manually also allows us to
have much more control over the produced values, so as a result of this
change, EasingStyleValue becomes much more ergonomic.
As the parser was trying to directly unwrap an unresolved duration.
Currently we are outputting the wrong results for the serialized
duration, but this is still a step forwards.
Fixes a crash seen on: https://evaparish.com/blog/how-i-edit
This URL library ends up being a relatively fundamental base library of
the system, as LibCore depends on LibURL.
This change has two main benefits:
* Moving AK back more towards being an agnostic library that can
be used between the kernel and userspace. URL has never really fit
that description - and is not used in the kernel.
* URL _should_ depend on LibUnicode, as it needs punnycode support.
However, it's not really possible to do this inside of AK as it can't
depend on any external library. This change brings us a little closer
to being able to do that, but unfortunately we aren't there quite
yet, as the code generators depend on LibCore.
From https://drafts.csswg.org/css-backgrounds-4/#background-clip
"The background is painted within (clipped to) the intersection of the
border box and the geometry of the text in the element and its in-flow
and floated descendants"
This change implements it in the following way:
1. Traverse the descendants of the element, collecting the Gfx::Path of
glyphs into a vector.
2. The vector of collected paths is saved in the background painting
command.
3. The painting commands executor uses the list of glyphs to paint a
mask for background clipping.
Co-authored-by: Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
When the caller of NumericCalculationNode::resolve() does not provide
a percentage_basis, it expects the method to return a raw percentage
value.
Fixes crashing on https://discord.com/login
Instead of serializing two calc() values to String and then comparing
those strings, we can now compare calc() values by actually traversing
their internal CalculationNode tree.
This makes style recomputation faster on pages with lots of calc()
values since it's now much cheaper to check whether a property with
some calc() value actually changed.
This change fixes GC-leak caused by following mutual dependency:
- SVGDecodedImageData owns JS::Handle for Page.
- SVGDecodedImageData is owned by visited objects.
by making everything inherited from HTML::DecodedImageData and
ListOfAvailableImages to be GC-allocated.
Generally, if visited object has a handle, very likely we leak
everything visited from object in a handle.
Before this change, we used Gfx::Bitmap to represent both decoded
images that are not going to be mutated and bitmaps corresponding
to canvases that could be mutated.
This change introduces a wrapper for bitmaps that are not going to be
mutated, so the painter could do caching: texture caching in the case
of GPU painter and potentially scaled bitmap caching in the case of CPU
painter.
Having two ways that `<position>` is represented is awkward and
unnecessary. So, let's combine the two paths together. This first step
copies and modifies the `parse_position()` code to produce a
`PositionStyleValue`.
Apart from returning a StyleValue, this also makes use of automatic enum
parsing instead of manually comparing identifier strings.
This modification introduces a new layer to the painting process. The
stacking context traversal no longer immediately calls the
Gfx::Painter methods. Instead, it writes serialized painting commands
into newly introduced RecordingPainter. Created list of commands is
executed later to produce resulting bitmap.
Producing painting command list will make it easier to add new
optimizations:
- It's simpler to check if the painting result is not visible in the
viewport at the command level rather than during stacking context
traversal.
- Run painting in a separate thread. The painting thread can process
serialized painting commands, while the main thread can work on the
next paintable tree and safely invalidate the previous one.
- As we consider GPU-accelerated painting support, it would be easier
to back each painting command rather than constructing an alternative
for the entire Gfx::Painter API.
Instead of resolving lengths used in the backdrop-filter during
painting, we can do that earlier in apply_style().
This change moves us a bit closer to the point when the stacking
context tree will be completely separated from the layout tree :)
Before this change, whenever ImageStyleValue had a non-null
`m_image_request`, it was always leaked along with everything related
to the document to which this value belongs. The issue arises due to
the use of `JS::Handle` for the image request, as it introduces a
cyclic dependency where `ImageRequest` prevents the `CSSStyleSheet`,
that owns `ImageStyleValue`, from being deallocated:
- ImageRequest
- FetchController
- FetchParams
- Window
- HTMLDocument
- HTMLHtmlElement
- HTMLBodyElement
- Text
- HTMLHeadElement
- Text
- HTMLMetaElement
- Text
- HTMLTitleElement
- Text
- HTMLStyleElement
- CSSStyleSheet
This change solves this by visiting `m_image_request` from
`visit_edges` instead of introducing new heap root by using
`JS::Handle`.
