We explicitly stopped visting the map of documents to console clients in
commit 44659f2f2a to avoid keeping the
document alive. However, if nothing else visits the console clients, we
may set the top-level console client to a client that has been garbage
collected.
So instead of storing this map, just store the console client on the
document itself. This will allow the document to visit its client.
(cherry picked from commit 0a819e628eb296200b8b5e609b4936a1a4bf330f)
This will allow testing if they are for fragment parsing during methods
invoked from Document::initialize.
(cherry picked from commit c838ca78c81261e6111aa255c79e4a0599759c80)
Before, we would compute and store the output of each predictor,
then pick the best one, and then copy its data.
Now, we compute the output of each predictor but only compute its
score and do not store the predicted data. We then pick the best
one, and do a second pass that re-computes the output of the best
predictor, and stores it.
Instead of computing the output of the 5 different predictors, we now
compute the output of the 5 different predictors, and then the output of
one of them again. In exchange, we only write each output row once
instead of 5 times. (We also have to read the input row twice instead of
once, but the second time round it'll come from L1 or L2.)
Making the simplifying assumption that each predictor takes the same
time to compute, this increases compute to 6/5th, and reduces memory
bandwidth to 3/6th. (Before: 1 input row read, 5 output row writes;
after: 2 input row reads, 1 output row write.)
Produces exactly the same output, but is faster:
image -o sunset_retro.png sunset_retro.bmp --png-compression-level 0
34.8 ms ± 0.9 ms -> 22.7 ms ± 0.8 ms (34.7% faster)
image -o sunset_retro.png sunset_retro.bmp --png-compression-level 1
64.2 ms ± 4.9 ms -> 50.5 ms ± 0.5 ms (31.3% faster)
image -o sunset_retro.png sunset_retro.bmp --png-compression-level 2
190.3 ms ± 1.6 ms -> 179.0 ms ± 2.8 ms (5.8% faster)
image -o sunset_retro.png sunset_retro.bmp --png-compression-level 3
646.5 ms ± 4.7 ms -> 635.3 ms ± 4.4 ms (3.3% faster)
Compression level 2 is the default, so about a 6% speedup in practice.
`sips` still needs 49.9 ms ± 3.0 ms to convert sunset_retro.bmp to
sunset_retro.png at its default compression level 1.
We used to take 1.27x as long as sips, now we take 1.01x as long,
while producing a smaller output :^)
(For other, larger, input files sips is still faster and produces
smaller output.)
Takes
(cd Tests/LibGfx; ../../Build/lagom/bin/BenchmarkPNG)
from 59ms to 32ms on my system.
Adds AK::SIMD::bitselect() (modeled after the wasm SIMD equivalent),
and AK::SIMD::abs() implemented on top of it.
No behavior change.
Writes to SharedInodeVMObjects could cause a Protection Violation if a
page was marked as dirty by a different process.
This happened due to a combination of 2 things:
* handle_dirty_on_write_fault() was skipped if a page was already marked
as dirty
* when a page was marked as dirty, only the Region that caused the page
fault was remapped
This commit:
* fixes the crash by making handle_fault() stop checking if a page was
marked dirty before running handle_dirty_on_write_fault()
* modifies handle_dirty_on_write_fault() so that it always marks the
page as dirty and remaps the page (this avoids a 2nd bug that was
never hit due to the 1st bug)
Resolve a regression caused by 01e1af732b.
This unbreaks coredump generation, because we need to use the VFS root
context of the crashed process and not of the FinalizerTask, as it will
hold an empty VFS root context that is assigned to kernel processes.
This commit adds a new test case which carries out the following steps:
* write() to a block of an ext2 file, verify the write() was successful
* read() the same block back, verify the read() was successful
* verify that the data from the read() is identical to the data that was
written in the write()
The test runs the above steps on the following blocks of an ext2 file:
* the first and last direct blocks
* the first and last singly indirect blocks
* the first and last doubly indirect blocks
* the first and last triply indirect blocks
Running in the microvm doesn't work anymore, since we removed IDE
support. Currently, we only support PCI(e)-attached storage devices,
which are not compatible with the microvm, as it doesn't support PCI(e)
at all.
Bulk transfers also use Normal TRBs, so move the reusable normal TRB
setup code from submit_async_interrupt_transfer into a new function
prepare_normal_transfer.
submit_bulk_transfer and submit_async_interrupt_transfer use this
function and then either block on the completion or submit it
asynchronously and wrap it into a PeriodicPendingTransfer.
Produces exactly the same output, but a bit faster.
The speedup is relatively bigger for worse compression:
image -o sunset_retro.png sunset_retro.bmp --png-compression-level 0
56.8 ms ± 1.5 ms -> 34.8 ms ± 0.9 ms (38.7% faster)
image -o sunset_retro.png sunset_retro.bmp --png-compression-level 1
84.6 ms ± 1.7 ms -> 64.2 ms ± 4.9 ms (24.1% faster)
image -o sunset_retro.png sunset_retro.bmp --png-compression-level 2
212.1 ms ± 2.5 ms -> 190.3 ms ± 1.6 ms (10.3% faster)
image -o sunset_retro.png sunset_retro.bmp --png-compression-level 3
671.4 ms ± 12.3 ms -> 646.5 ms ± 4.7 ms (3.7% faster)
Compression level 2 is the default, so about a 10% speedup in practice.
For comparison, `sips` needs 49.9 ms ± 3.0 ms to convert
sunset_retro.bmp to sunset_retro.png, and judging from the output file
size, it uses something similar to our compression level 1.
We used to take 1.7x as long as sips, now we take 1.29x as long.
Previously we made one thread pool per ipc client, which is excessive
and can eat up all the available fds very fast.
This is a manual port of commit 18499c4eac301db7e8915284f33766ca96cdeef2
from Ladybird.
Regular `realpath` seems to work fine.
This removes the last coreutils dependency from BuildClang.sh.
It can now run on a system that has just ninja and cmake and Xcode
installed.
No intended behavior change.
When building with the GNU toolchain, /usr/local/lib and
/usr/local/include are among the default search paths for the compiler
and linker. It seems that this is not the case for Clang/LLVM, and thus
some packages fail to build, while others silently drop optional deps.
This commit adds those paths back, fixing multiple packages at once.
Additionally, it removes legacy -I/-L includes in various Ports which
are no longer needed.
Co-Authored-By: Nico Weber <thakis@chromium.org>
Instead of using a raw `KBuffer` and letting each implementation to
populating the specific flags on its own, we change things so we only
let each FileSystem implementation to validate the flag and its value
but then store it in a HashMap which its key is the flag name and
the value is a special new class called `FileSystemSpecificOption`
which wraps around `AK::Variant<...>`.
This approach has multiple advantages over the previous:
- It allows runtime inspection of what the user has set on a `MountFile`
description for a specific filesystem.
- It ensures accidental overriding of filesystem specific option that
was already set is not possible
- It removes ugly casting of a `KBuffer` contents to a strongly-typed
values. Instead, a strongly-typed `AK::Variant` is used which ensures
we always get a value without doing any casting.
Please note that we have removed support for ASCII string-oriented flags
as there were no actual use cases, and supporting such type would make
`FileSystemSpecificOption` more complicated unnecessarily for now.
In the current code, these are treated as if they were a bitmap. They
are not, and (DT_REL & DT_RELA) is actually nonzero. This causes the
linker to treat all sections as having addends, which is not correct.
Before this change, we were passing them as Gfx::ShareableBitmap. The
problem is that shareable bitmaps keep their underlying file descriptor
open, so that they can be shared again with someone else.
When a Gfx::Bitmap is decoded from an IPC message, the file descriptor
is closed and recovered immediately.
This fixes an issue where we'd accumulate one file descriptor for every
image decoded. This eventually led to descriptor starvation after enough
images were loaded and still referenced at the same time.
(cherry picked from commit 166e603c5eb0a103eea148baf97a075fe5fea964)
In upcoming changes, bitmap is going to be used to wrap the memory of
the IOSurface, and we will want to release the corresponding IOSurface
along with the bitmap.
(cherry picked from commit 3110411c60f0c5f9860ba9de4d229e246afadb62;
amended to fix trivial conflicts arising from serenityos still having an
`intrinsic_scale` argument that ladybird removed. We don't need this
commit for IOSurfaces, but for the use added in
LadybirdBrowser/ladybird#688)
This change makes OpenType::Name::string_for_id handle fonts whose names
are UTF-16-encoded (along with handling UTF-8-encoded names).
Otherwise, without this change, the existing code assumes the names are
UTF-8-encoded, fails gracelessly if they’re not, and crashes.
Fixes https://github.com/LadybirdBrowser/ladybird/issues/75
(cherry picked from commit 1a9dabe5ff443315a1e3e9c577f93936e6dd45dc)
