As mentioned in F.2.1.5 - Inverse DCT (IDCT), the decoder needs to
perform a level shift by adding 128. This used to be done in
`ycbcr_to_rgb` after the conversion. Now, we do it in `inverse_dct` in
order to ensure that the task is done unconditionally.
Consequences of this are that we are no longer required to explicitly
do it for RGB images and also, the `ycbcr_to_rgb` function is exactly
like the specification.
When reading the stream, interpreted as a normal value 0xF0 means skip
15 values and assign the 16th to 0. On the other hand, the marker ZRL
- which has the value 0xF0, means skip 16 values. For baseline JPEGs,
ZRL doesn't need to be interpreted differently as writing the 16th value
has no consequence. This is no longer the case with refining scans.
That's why this patch implement correctly ZRL.
We used to skip over zero coefficient by modifying the loop counter. It
is unfortunately impossible to perform this with SOF2 images as only
coefficients with a zero-history should be skipped.
This induces no behavior change for the user of the function.
This commit is nonsense for anything else than SOF2 images with spectral
approximation. For this particular case, skips like EOB or ZRL only
apply to coefficients with a zero-history. This commit prepares the code
to handle this behavior.
Rather than the very C-like API we currently have, accepting a void* and
a length, let's take a Bytes object instead. In almost all existing
cases, the compiler figures out the length.
This helper constructor exists on the unspecialized Span<T> class also,
and is convenient for e.g. creating Bytes from:
u8 buffer[64];
Bytes bytes { buffer };
From the getentropy() man page, "The maximum permitted value for the
length argument is 256". Several of our tests were passing lengths of
several thousand bytes, causing getentropy() to fail with EIO, which we
were completely ignoring. This caused these tests to only test long
sequences of 0x00.
We now loop over the provided buffer to fill it 256 bytes at a time. If
getentropy() fails for any reason, we fall back to the default method of
filling it with one random byte at a time.
This function has probably been added when we weren't as good with error
propagations as we are now. We can safely remove it and let future
calls to `read` fail if the file is corrupted.
This can be tested with the following bytes (already used in 9191829a):
ffd8ffc000000800080ef701101200ffda00030100
This matches x86_64's behaviour in common_trap_exit. (called from
thread_context_first_enter)
Currently thread_context_first_enter is only called when creating new
processes from scratch, in which case this doesn't change the actual
behaviour. But once thread_context_first_enter is called as part of
execve support, this will ensure the Thread's m_current_trap is set
correctly to the new trap frame.
The details of the specific interrupt bits that must be turned on are
irrelevant to the sys$execve implementation. Abstract it away to the
Processor implementations using the InterruptsState enum.
Forked processes already have an existing value for the link register,
which we can't overwrite. But since they're forked the original link
register value that points to exit_kernel_thread was already saved
somewhere on the stack, so it's ok not to set it.
When trying to set the wallpaper from the menu, ImageViewer would
crash because setting the wallpaper requires the program to pledge
to the WindowManager domain. This patch adds that pledge.
This parses the new background-position-x/y longhands and properly
hooks up them up. This requires converting PositionStyleValue to
just contain two EdgeStyleValues so that it can be easily expanded
into the longhands.
This solves the longhands must be initialized before shorthands
problem by just initializing the value when it is first requested.
This will be needed for background-position-x/y which is a longhand
of a longhand, which otherwise breaks the longhands before shorthands
rule.
This commit fixes a kernel panic that happened when unmounting
a disk due to an invalid memory access.
This was because `DiskCache` initializes two linked lists that use
an argument `KBuffer` as the storage for their elements.
Since the member `KBuffer` was declared after the two lists,
when `DiskCache`'s destructor was called, then `KBuffer`'s destructor
was called before the ones of the two lists, causing a page fault in
the kernel.
This is very similar to the LittleEndianInputBitStream bit buffer change
from 8e834d4bb2.
We currently buffer one byte of data for the underlying stream. And when
we put bits onto that buffer, we do so 1 bit at a time.
This replaces the u8 buffer with a u64. And instead of looping at all,
we perform bitwise operations to write 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), compression time
decreases from:
13.62s to 10.9s on Serenity (cold)
13.62s to 9.22s on Serenity (warm)
2.93s to 2.32s on Linux
One caveat is that this requires explicitly flushing any leftover bits
when the caller is done with the stream. The byte buffer implementation
implicitly flushed its data every time the buffer was byte-aligned, as
doing so would always fill the byte. This is no longer the case. But for
now, this should be fine as the one user of this class, DEFLATE, already
has a "flush everything now that we're done" finalizer.
This is something we're supposed to do according to the HTML spec.
Note that image loading is currently completely ad-hoc, and this just
adds a simple DocumentLoadEventDelayer to the existing implementation.
This will allow us to use images in layout tests, which rely on the
document load event firing at a predictable time.
Instead of passing the continuously merged initial forbidden token set
(with the new additional forbidden tokens from each parsed secondary
expression) to the next call of parse_secondary_expression(), keep a
copy of the original set and use it as the base for parsing the next
secondary expression.
This bug prevented us from properly parsing the following expression:
```js
0 ?? 0 ? 0 : 0 || 0
```
...due to LogicalExpression with LogicalOp::NullishCoalescing returning
both DoubleAmpersand and DoublePipe in its forbidden token set.
The following correct AST is now generated:
Program
(Children)
ExpressionStatement
ConditionalExpression
(Test)
LogicalExpression
NumericLiteral 0
??
NumericLiteral 0
(Consequent)
NumericLiteral 0
(Alternate)
LogicalExpression
NumericLiteral 0
||
NumericLiteral 0
An alternate solution I explored was only merging the original forbidden
token set with the one of the last parsed secondary expression which is
then passed to match_secondary_expression(); however that led to an
incorrect AST (note the alternate expression):
Program
(Children)
ExpressionStatement
LogicalExpression
ConditionalExpression
(Test)
LogicalExpression
NumericLiteral 0
??
NumericLiteral 0
(Consequent)
NumericLiteral 0
(Alternate)
NumericLiteral 0
||
NumericLiteral 0
Truth be told, I don't know enough about the inner workings of the
parser to fully explain the difference. AFAICT this patch has no
unintended side effects in its current form though.
Fixes#18087.
