| Age | Commit message (Collapse) | Author |
|---|
|
This is going to hold other per-line data too.
|
|
|
|
Warn the user about seemingly known malloc() and free() patterns in the
fault address.
This brings back the functionality that was removed recently in the
5416a37fdea815b2fc18c35a60d173f8cfa67709 commit, but this time we detect
these patterns in userspace code and not in kernel code.
|
|
Calling umask and open with same permission value will result in a file
with no permissions bits if the program is stopped while it is doing an
IO. This will result in an error with EACCES when we try to run the
benchmark with the same file name. The file needs to be manually
removed before continuing the benchmark.
There is no use in calling umask here, so just remove it so that
interrupting the program while it is doing an IO will not result int the
file with no permissions the next time we run the program.
|
|
Instead of reading bytes from the output stream into a buffer, just to
immediately write them back out, we can skip the middle-man and copy the
bytes directly into the output buffer.
|
|
Co-authored-by: Andreas Kling <kling@serenityos.org>
|
|
This implements Intel's slicing-by-8 algorithm for CRC checksums (only
little endian CPUs for now, as I don't have a way to test big endian).
The original paper for this algorithm seems to have disappeared, but
Intel's source code is still available as a reference:
https://sourceforge.net/projects/slicing-by-8/
As well as other implementations for reference:
https://docs.rs/slice-by-8/latest/src/slice_by_8/algorithm.rs.html
Using the "enwik8" file as a test (100MB uncompressed, commonly used in
benchmarks: https://www.mattmahoney.net/dc/enwik8.zip), decompression
time decreases from:
4.89s to 3.52s on Serenity (cold)
1.72s to 1.32s on Serenity (warm)
1.06s to 0.92s on Linux
|
|
This was fine before as the last entry was a null string (which could be
printed), but we no longer use C-style sentinel-terminated arrays for
arguments.
|
|
|
|
|
|
This solves an awkward dependency cycle, where CalculatedStyleValue
needs the definition of Percentage, but including that would also pull
in PercentageOr, which in turn needs CalculatedStyleValue.
Many places that previously included StyleValue.h no longer need to. :^)
|
|
There were a mix of users between those who want to know if the Length
changed, and those that just want an absolute Length. So, we now have
two methods: Length::absolutize() returns an empty Optional if nothing
changed, and Length::absolutized() always returns a value.
|
|
There's no longer any reason to have this in StyleValue.h
|
|
It's in Position.{h,cpp} because it represents a <position> in CSS, even
though it's currently named PositionValue to avoid collisions.
|
|
Also remove the unused StyleValue::to_rect() because an EdgeRect is only
ever held by a RectStyleValue.
|
|
Again, this doesn't belong in StyleValue.h, though this may not be the
ideal place for it either.
|
|
This may not be the ideal place for this, but it definitely doesn't
belong in StyleValue.h
|
|
|
|
Technically this was already true, but now we explicitly allow it
instead of that calc value being hidden inside a Length or Percentage.
|
|
Time also isn't used anywhere yet, hooray!
|
|
Conveniently, we don't actually use Frequency for any properties.
|
|
...and replace it with AngleOrCalculated.
This has the nice bonus effect of actually handling `calc()` for angles
in a transform function. :^) (Previously we just would have asserted.)
|
|
This is intended as a replacement for Length and friends each holding a
`RefPtr<CalculatedStyleValue>`. Instead, let's make the types explicit
about whether they are calculated or not. This then means a Length is
always a Length, and won't require including `StyleValue.h`.
As noted, it's probably nicer for LengthOrCalculated to live in
`Length.h`, but we can't do that until Length stops including
`StyleValue.h`.
|
|
6.6% speed-up on Kraken's stanford-crypto-aes subtest. :^)
|
|
Due to CSSImportRule::has_import_result() being backwards, we never
actually entered imported style sheets when traversing style rules or
media queries.
With this fixed, we no longer need the "collect style sheets" step in
StyleComputer, as normal for_each_effective_style_rule() will now
actually find all the rules. :^)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The constructor is now only concerned with creating the required
streams, which means that it no longer fails for XZ streams with
invalid headers. Instead, everything is parsed and validated during the
first read, preparing us for files with multiple streams.
|
|
This was causing a huge slowdown when loading some pages with weirdly
huge number of style sheets. For example, amazon.com has over 200 style
elements, which meant we had to resort the StyleSheetList 200 times.
(And sorting itself was slow because it has to compare DOM positions.)
Instead of sorting, we now look for the correct insertion point when
adding new style sheets, and we start the search from the end, which is
where style sheets are typically added in the vast majority of cases.
This removes a 600ms time sink when loading Amazon on my machine! :^)
|
|
This will allow other parts of LibWeb to understand these values.
|
|
Setting the `data` of a text node already triggers `children changed`
per spec, so there's no need for an explicit call.
This avoids parsing every HTMLStyleElement sheet twice. :^)
|
|
The issue was that the buffer would only be filled if it was empty.
|
|
We currently only fill a buffer when it is empty. So if it has 1 byte
and 16 KB was requested, only that 1 byte would be returned. Instead,
attempt to refill the buffer when it's size is less than the requested
size.
|
|
When reading, we currently only fill a BufferedStream's buffer when it
is empty, and only with 1 KB of data. This means that while the buffer
defaults to a size of 16 KB, at least 15 KB is always unused.
|
|
|
|
|
|
The current implementation of `Array<T, 0>` has a zero-length C array as
its storage type. While this is accepted as a GNU extension, when
compiling with Clang 16, an UBSan error is raised every time an object
is accessed whose only field is a zero-length array.
This is likely a bug in Clang 16's implementation of UBSan, which has
been reported here: https://github.com/llvm/llvm-project/issues/61775
|
|
We now select between nearest neighbor and bilinear filtering when
scaling images in CRC2D.drawImage().
This patch also adds CRC2D.imageSmoothingQuality but it's ignored for
now as we don't have a bunch of different quality levels to map it to.
Work towards #17993 (Ruffle Flash Player)
|
|
...instead of not resolving them at all. :^)
|
|
We currently decode back-references one byte at a time, while writing
that byte back out to the output buffer. This is only necessary when the
back-reference refers to itself, i.e. when the back-reference distance
is less than its length. In other cases, we can read the entire back-
reference block in one shot.
Using the "enwik8" file as a test (100MB uncompressed, commonly used in
benchmarks: https://www.mattmahoney.net/dc/enwik8.zip), decompression
time decreases from:
5.8s to 4.89s on Serenity (cold)
2.3s to 1.72s on Serenity (warm)
1.6s to 1.06s on Linux
|
|
Else:
AK/BitStream.h:218:24:
error: inline function '...::lsb_mask<unsigned char>' is not
defined [-Werror,-Wundefined-inline]
static constexpr T lsb_mask(T bits)
^
|
|
|
|
Huffman codes have a useful property in that they are prefix codes. That
is, a set of bits representing a Huffman-coded symbol is never a prefix
of another symbol. This allows us to create a table, where each index in
the table are integers whose prefix is the entry's corresponding Huffman
code.
With Deflate, we can have codes up to 16 bits in length, thus creating a
prefix table with 2^16 entries. So instead of creating a table fit all
possible codes, we use a cutoff of 8-bit codes. Codes larger than 8 bits
fall back to the binary search method.
Using the "enwik8" file as a test (100MB uncompressed, commonly used in
benchmarks: https://www.mattmahoney.net/dc/enwik8.zip), decompression
time decreases from 3.527s to 2.585s on Linux.
|
|
We current buffer one byte of data from the underlying stream. And when
we pull bits off that buffer, we do so 1 or 8 bits at a time (depending
on whether the buffer is byte aligned). The 1-bit-at-a-time loop is by
far the most common during e.g. GZIP decompression.
This replaces the u8 buffer with a u64. And instead of looping at all,
we perform bitwise operations to extract the desired number of bits.
Using the "enwik8" file as a test (100MB uncompressed, commonly used in
benchmarks: https://www.mattmahoney.net/dc/enwik8.zip), decompression
time decreases from:
242s to 35s on Serenity
11.125s to 3.527s on Linux
Note that BigEndianInputBitStream can also use the same techniques,
and some of the methods here may make sense to live in an endianness-
agnostic base class. The focus is GZIP right now though, which only
uses the little endian stream.
|
|
We currently mix normal and bit streams during GZIP decompression, where
the latter is a wrapper around the former. This isn't causing issues now
as the underlying bit stream buffer is a byte, so the normal stream can
pick up where the bit stream left off.
In order to increase the size of that buffer though, the normal stream
will not be able to assume it can resume reading after the bit stream.
The buffer can easily contain more bits than it was meant to read, so
when the normal stream resumes, there may be N bits leftover in the bit
stream that the normal stream was meant to read.
To avoid weird behavior when mixing streams, this changes the GZIP
decompressor to always read from a bit stream.
|
