This patch introduces the StyleComputer::RuleCache, which divides all of
our (author) CSS rules into buckets.
Currently, there are two buckets:
- Rules where a specific class must be present.
- All other rules.
This allows us to check a significantly smaller set of rules for each
element, since we can skip over any rule that requires a class attribute
not present on the element.
This takes the typical numer of rules tested per element on Discord from
~16000 to ~550. :^)
We can definitely improve the cache invalidation. It currently happens
too often due to media queries. And we also need to make sure we
invalidate when mutating style through CSSOM APIs.
Previously we would re-run the entire CSS selector machinery for each
property resolved. Instead of doing that, we now resolve a final set of
custom property key/value pairs at the start of the cascade.
- Replace "auto" with "auto const" where appropriate.
- Remove an unused struct.
- Make sort_matching_rules() a file-local static function.
- Remove some unnecessary includes.
In the ThrowCompletionOr constructors, the VERIFY statements are using
moved-from objects. We should not rely on those objects still being
valid after being moved.
Before this would assume that the element found in operator++ was still
valid when dereferencing it in operator*.
Since any code can have been run since that increment this is not always
valid.
To further simplify the logic of the iterator we no longer store the
index in an optional.
The existing SQLResult class predates our TRY semantics. As a result, in
the AST execution methods, there is a lot of is_error checking on values
that could instead be wrapped with TRY. This new class will allow such
semantics, and is also stack allocated (no need to be a RefPtr). It is
heavily based on LibJS's completion class.
The `ClipPlane` enum is being looped over at run-time performing
run-time dispatch to determine the comparison operation in
`point_within_clip_plane`.
Change this `for` loop to be linear code which dispatches using a
template parameter. This allows for the `point_within_clip_plane`
function to do compile-time dispatch.
Note: This linear code can become a compile-time loop when static
reflection lands in C++2[y|z] allowing looping over the reflected
`enum class`.
This implements ordered sets using Maps with a sentinel value, and
includes some extra set tests.
Fixes#11004.
Co-Authored-By: davidot <davidot@serenityos.org>
...even if the headers claim that there's some data in the form of
Content-Length.
This finally fixes loading Discord with RequestServer ConnectionCache
on :^)
Our previous code roughly did this:
1. Generate a bitmap as large as the shadow would end up.
2. Paint a rectangle onto it.
3. Blur the whole bitmap.
4. Split it up and render each section.
This patch takes advantage of the fact that (aside from corners) each
horizontal or vertical strip of a box-shadow is identical to the
others, to generate and blur a much smaller bitmap - only large enough
for the four corners and 1px of central "side" in each direction. This
greatly reduces the memory footprint, and should also speed things up,
since there is much less to blur.
This initial implementation stubs out the WorkerGlobalScope,
WorkerLocation and WorkerNavigator classes. It doesn't take into account
all the things that actually need passed into the constructors for these
objects, nor the extra abstract operations that need to be performed on
them by the rest of the Browser infrastructure. However, it does create
bindings that compile and link :^)
While trying to get http://lite.duckduckgo.com to work in the Browser I
noticed that we kept on getting 400 (Bad Request) errors when you click
the "Search" button for a request.
After turning on `JOB_DEBUG` to see what headers we were sending it
turned out that we were actually setting `Content-Length` twice once
in LibWeb, and again when the request is handled by LibHTTP.
Since LibHTTP transparently handles this now, we can avoid it in LibWeb.
Before this, we were filling and stroking every <path>, whether they had
a fill/stroke color or not. We can avoid a bunch of unnecessary work by
checking if the color is transparent (also the case if unset) before
doing the painting work.
If there is no fill color, we also avoid making a copy of the path to
ensure that it's closed.
Resolve TODOs suggesting the use of a strongly typed MarkedValueList
(a.k.a. MarkedVector<T>) in the following AOs:
- get_possible_instants_for()
- disambiguate_possible_instants()
Note: MarkedVector is still relatively new and has zero users right now,
so these changes don't affect any code other than the class itself.
Reasons for this are the rather limited API:
- Despite the name and unlike MarkedValueList, MarkedVector isn't
actually a Vector, it *wraps* a Vector. This means that plenty of
convenient APIs are unavailable and have to be exported on the class
separately and forwarded to the internal Vector, or need to go through
the exposed Span - both not great options.
- Exposing append(Cell*) and prepend(Cell*) on the base class means that
it was possible to append any Cell type, not just T! All the strong
typing guarantees are basically gone, and MarkedVector doesn't do much
more than casting Cells to the appropriate type through the exposed
Span.
All of this combined means that MarkedVector - in its current form -
doesn't provide much value over MarkedValueList, and that we have to
maintain two separate, yet almost identical classes.
Let's fix this!
The updated MarkedVector steals various concepts from the existing
MarkedValueList, especially the ability to copy. On the other hand, it
remains generic enough to handle both Cell* and Value for T, making
MarkedValueList effectively redundant :^)
Additionally, by inheriting from Vector we get all the current and
future APIs without having to select and expose them separately.
MarkedVectorBase remains and takes care of communicating creation and
destruction of the class to the heap. Visiting the contained values is
handled via a pure virtual method gather_roots(), which is being called
by the Heap's function of the same name; much like the VM has one.
From there, values are added to the roots HashTable if they are cells
for T = Value, and unconditionally for any other T.
As a small additional improvement the template now also takes an
inline_capacity parameter, defaulting to 32, and forwards it to the
Vector template; allowing for possible future optimizations of current
uses of MarkedValueList, which hard-codes it to 32.
The global variable use in these functions is super thread-unsafe and
means that any concurrent calls to sprintf or fprintf in a process
could race with each other and end up writing unexpected results.
We can just replace the function + global variable with a lambda that
captures the relevant argument when calling printf_internal instead.
The SemanticSyntaxHighlighter uses TokenInfo results from the
language server to provide 'semantic' syntax highlighting, which
provides more fin-grained text spans results.
For example, the SemanticSyntaxHighlighter can color function calls,
member fields references and user-defined types in different colors.
With the simple lexer-only syntax highlighter, all of these tokens were
given the same text highlighting span type.
Since we have to provide immediate highlighting feedback to the user
after each edit and before we get the result for the language server,
we use a heuristic which computes the diff between the current tokens
and the last known tokens with compete semantic information
(We use LibDiff for this).
This heuristic is not very performant, and starts feeling sluggish with
bigger (~200 LOC) files.
A possible future improvement would be only computing the diff for
tokens in text ranges that have changes since the last commit.
The TokenInfo struct contains the token's position and a
"semantic type". The semantic type is a more fine-grained token type
than what's in Cpp::Token::Type.
For example, the semantic token type differentiates between a reference
to a variable and to a function parameter. In the normal Token::Type,
both would be Token::Type::Identifier.
