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)
The sysret instruction restores the rflags value from the r11 register.
Before, we expected that the value in RegisterState::r11 is still the
rflags value saved by syscall and therefore didn't copy
RegisterState::rflags to r11 before the sysret.
But signal handlers and ptrace can change the value in
RegisterState::r11 while we are handling a syscall, so we shouldn't
assume that it still contains the saved rflags.
While handling a syscall the contents of RegisterState::rflags may also
have been updated by e.g. ptrace in which case we should restore the
updated rflags, not the original state on syscall entry.
This prevents a crash in ImageDecoder when it's closed before any
image decoding requests have been made.
(cherry picked from commit 88176d4be2339108d9d54b8af62f5438f9c82f30)
We need to do this to stop the animation timer and delete the current
animation, otherwise the new image will be shown only for a moment
before the previous animation continues.
The numbers in the previous commit show that going from n = 2 to
n = 3 comes with a big cost in runtime (3-4 times as long) for a
very modest to modest size win (0.5% to 2.5%). The jumps from n = 0
to n = 1 and from n = 1 to n = 2 look much more reasonable.
If image size is the main concern, webp is a better option now.
If PNG size is a big concern, recompressing with something like
zopflipng is currently still necessary anyways.
All in all, I think Default is the better default compression level now.
This effectively reverts #14738.
Affects PNGs written by all apps in the system (PixelPaint, Mandelbrot,
LibWeb's HTMLCanvasElement png serialization, LibWeb's screenshot
feature, `shot`, SpiceAgent, Magnify, `pdf` output, `image` without
--png-compression-level flag).
Using the same two benchmarks as in the previous commit:
1.
n | time | size
--+--------------------+--------
0 | 56.5 ms ± 0.9 ms | 2.3M
1 | 88.2 ms ± 14.0 ms | 962K
2 | 214.8 ms ± 5.6 ms | 908K
3 | 670.8 ms ± 3.6 ms | 903K
Compared to the numbers in the previous commit:
n = 0: 17.3% faster, 23.3% smaller
n = 1: 12.9% faster, 12.5% smaller
n = 2, 24.9% faster, 9.2% smaller
n = 3: 49.6% faster, 9.6% smaller
For comparison,
`sips -s format png -o sunset_retro_sips.png sunset_retro.bmp` writes
a 1.1M file (i.e. it always writes RGBA, not RGB when not necessary),
and it needs 49.9 ms ± 3.0 ms for that (also using a .bmp input). So
our output file size is competitive! We have to get a bit faster though.
For another comparison, `image -o sunset_retro.webp sunset_retro.bmp`
writes a 730K file and needs 32.1 ms ± 0.7 ms for that.
2.
n | time | size
--+----------------+------
0 | 11.334 total | 390M
1 | 13.640 total | 83M
2 | 15.642 total | 73M
3 | 48.643 total | 71M
Compared to the numbers in the previous commit:
n = 0: 15.8% faster, 25.0% smaller
n = 1: 15.5% faster, 7.7% smaller
n = 2: 24.0% faster, 5.2% smaller
n = 3: 29.2% faster, 5.3% smaller
So a relatively bigger speed win for higher levels, and
a bigger size win for lower levels.
Also, the size at n = 2 with this change is now lower than it
was at n = 3 previously.
No change to the default behavior.
This allows collecting some statistics.
1.
hyperfine --warmup 1 \
'Build/lagom/bin/image -o sunset_retro.png sunset_retro.bmp \
--png-compression-level $n'
n | time | size
--+-------------------------+--------
0 | 68.3 ms ± 3.8 ms | 3.0M
1 | 101.3 ms ± 2.1 ms | 1.1M
2 | 286.0 ms ± 2.5 ms | 1.0M
3 | 1.331 s ± 0.005 s | 999K
2.
Using the benchmarking script from #24819, just changed to write
.png files with different --png-compression-level values:
n | time | size
--+----------------+------
0 | 13.467 total | 520M
1 | 16.151 total | 90M
2 | 20.592 total | 77M
3 | 1:08.69 total | 75M
(cherry picked from commit 75216182c9a04741b2f773eb2f26ceb7a96bfbba)
(cherry picked from commit 2a55ab13ef9c735a16674006a518c0e5acf7c88f)
Co-authored-by: Sam Atkins <atkinssj@serenityos.org>
`Module::functions` created clones of all of the functions in the
module. It provided a _slightly_ better API, but ended up costing around
40ms when instantiating spidermonkey.
(cherry picked from commit dc52998341bb86ad8fb790fb72f943e43b16e8e5)
Unroll the first byte as a fast path, and remove a branch. This speeds
up the instantiation of spidermonkey by 10ms.
(cherry picked from commit a6ebd100ecd9ed633e290153f61466362e63b73a)
Instead of multiple loops and multiple vectors, parse Wasm expressions
in a simple loop. This gets us from ~450ms to instantiate spidermonkey
to ~280ms.
(cherry picked from commit 2cfc1873c0436f598f897dd84172b753e2c2b03c)
`swizzle` had the wrong operands, and the vector masking boolean logic
was incorrect in the internal `shuffle_or_0` implementation. `shuffle`
was previously implemented as a dynamic swizzle, when it uses an
immediate operand for lane indices in the spec.
(cherry picked from commit 9cc3e7d32d150dd30d683c1a8cf0bd59676f14ab)
