There's no need to copy the result. We can also avoid increasing the
size of the output buffer by 1 for each written byte.
This reduces the runtime of `./bin/base64 -d enwik8.base64 >/dev/null`
from 0.917s to 0.632s.
(enwik8 is a 100MB test file from http://mattmahoney.net/dc/enwik8.zip)
We don't really need the features provided by StringBuilder here, since
we know the exact size of the output. Avoiding StringBuilder avoids the
recurring capacity/size checks both within StringBuilder itself and its
internal ByteBuffer.
This reduces the runtime of `./bin/base64 enwik8 >/dev/null` from
0.976s to 0.428s.
(enwik8 is a 100MB test file from http://mattmahoney.net/dc/enwik8.zip)
We know we are only appending ASCII characters to the StringBuilder, so
do not bother validating the result.
This reduces the runtime of `./bin/base64 enwik8 >/dev/null` from
1.192s to 0.976s.
(enwik8 is a 100MB test file from http://mattmahoney.net/dc/enwik8.zip)
Instead of invalidating animated style properties whenever
`Document::update_style()` is called, now we only do that when
animations might have actually progressed. We still have to ensure
animated properties are up-to-date in `update_style()` to ensure that
JS methods can access updated style properties.
Before this change, we ran style and layout updates from both event
loop processing and update timers. This could have caused missed resize
observer updates and unnecessary updating of style or layout more than
once before repaint.
Also, we can now be sure unnecessary style or layout updates won't
happen in `EventLoop::spin_processing_tasks_with_source_until()`.
In our implementation of the "apply the history step" algorithm, we
have to spin-wait for the completion of tasks queued on the event loop.
Before this change, we allowed tasks from any source to be executed
while we were waiting. It should not be possible because it allows to
interrupt history step application by anything, including another
history step application.
Fixes https://github.com/SerenityOS/serenity/issues/23598
This encoding scheme comes from section 5 of RFC 4648, as an
alternative to the standard base64 encode/decode methods.
The only difference is that the last two characters are replaced
with '-' and '_', as '+' and '/' are not safe in URLs or filenames.
You can now run
image -o out.png Tests/LibGfx/test-inputs/bmp/bitmap.bmp \
--crop 130,86,108,114
and end up with the nose part of that image in out.png.
This isn't required as the StyleComputer will do this when animating,
but this allows the properties to be resolved once instead of on
every animation frame.
Note that we still pass AllowUnresolved::Yes because the properties will
not be resolved if there is no target.
When iterating through a @keyframes rule, it isn't possible to resolve
unresolved style properties since there are no elements. This change
allows those properties to simply pass through this helper function.
These will need to store unresolved styles as well, since they may be
built during parsing of a @keyframes rule. In that case there is no
target element or pseudo-element, and thus the value cannot be resolved.
structured_deserialize_internal() is added to support sub
deserialization from serializable interfaces serialization steps which
needs the ability to pass onto the current position in the deserialized
data.
This value is at most 46, so a u8 is enough.
We have tens of thousands of these contexts.
(We could pack the is_mps bit into that u8 as well, but
then the I() and MPS() functions need to return helper objects
instead of a direct reference, so let's not do that part for now.)
If a lossless webp has 3 or 4 colors, it uses 2 bits per pixel to
store an offset into a "color index" (which the spec explicitly does
not call palette since it says the 'color cache' is more like that).
This way, it can pack 4 pixels into a single pixel.
If the width of the output image wasn't evenly divisble by 4,
we used to write out-of-bounds in the last few columns of each
row, since we used to always write all 4 pixels.
Found by clusterfuzz. Probably fixes
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=66082
While here, spruce up the comments very slightly.
If an unexpected token is encountered when parsing an SVG attribute it
is now immediately propagated with ErrorOr. Previously, some situations
where an unexpected token was encountered could cause a crash.
If `Document::resolve()` was called during parsing, it'd change the
reader's current position, so the parsing code that called it would
then end up at an unexpected position in the file.
Parser.cpp already had special-case recovery when a stream's length
was stored in an indirect reference.
Commit ead02da98a ("/JBIG2Globals") in #23503 added another case
where we could resolve indirect reference during parsing, but wasn't
aware of having to save and restore the reader position for that.
Put the save/restore code in `DocumentParser::parse_object_with_index`
instead, right before the place that ultimately changes the reader's
position during `Document::resolve`. This fixes `/JBIG2Globals` and
lets us remove the special-case code for `/Length` handling.
Since this is kind of subtle, include a test.
This test uses a JBIG2Globals with an indirect reference,
and contains an indirect reference for a stream length.
When we parse the main JBIG2 image's stream, we unfilter
its data, which causes these two indirect references to
be resolved during parsing.
I started with the output of
Meta/jbig2_to_pdf.py -o foo.pdf \
Tests/LibGfx/test-inputs/jbig2/bitmap.jbig2
and then manually added a
/DecodeParms <</JBIG2Globals 6 0 R>>
entry pointing to an empty stream, and made that new stream
object's length an indirect reference too for good measure.
I used `mutool clean` to fix up offsets a bit. But that also
removes the indirect reference for a stream's length, so I
manually put that back in and adjusted the offset to the last
object in the xref table and the startxref value.
Use the new DOM tree version mechanism to allow HTMLCollection to
remember its internal list of elements instead of rebuilding it on
every access.
This avoids thousands of full DOM walks while loading our GitHub repo.
~15% speed-up on jQuery subtests in Speedometer 3.0 :^)
This patch adds a u64 version counter to DOM::Document that increments
whenever the tree structure changes (via node insertion or removal),
or an element attribute is changed somehow.
This will be used as a crude invalidation mechanism for HTMLCollection
to cache its elements.
- Compare only the animated properties
- Clone only the hash map containing animated properties, instead of
the entire StyleProperties.
Reduces `KeyframeEffect::update_style_properties()` from 10% to 3% in
GitHub profiles.
Non-recursive pseudo classes are easy to evaluate, so let's allow them
on the fast path.
Increases fast path coverage when loading our GitHub repo from 48% to
56% of all selectors evaluated.
If we determine that a selector is simple enough, we now run it using a
special matching loop that traverses up the DOM ancestor chain without
recursion.
The criteria for this fast path are:
- All combinators involved must be either descendant or child.
- Only tag name, class, ID and attribute selectors allowed.
It's definitely possible to increase the coverage of this fast path,
but this first version already provides a substantial reduction in time
spent evaluating selectors.
48% of the selectors evaluated when loading our GitHub repo are now
using this fast path.
18% speed-up on the "Descendant and child combinators" subtest of
StyleBench. :^)
