(Instead of MarkedVector<Value>.) This is a step towards not storing
argument lists in MarkedVector<Value> at all. Note that they still end
up in MarkedVectors since that's what ExecutionContext has.
This is an extension of cc0b970d but for the reference-handling
specialization of Optional.
This basically allow us to write code like:
```cpp
Optional<u8&> opt;
opt = OptionalNone{};
```
We're seeing timeouts for WebWorker based tests in some CI runs. It's
possible that these are legitimate timeouts, so bump the default timeout
to 30sec. When porting the test runner to run on CI, Andreas had to bump
the test timeout from 5 seconds to 10, to 15. It's likely that loading
our ASAN/UBSAN binaries on slow CI machines takes a significant amount
of time. Tests that use the new WebWorker process are spawning yet
another process that needs to load LibWeb and all its dependencies.
These can be quite verbose on the command line if the packages aren't
found. As they do not break the build, let's not spam warnings.
The OpenGL package is also now skipped on macOS, where there's no point
in looking for the package anyways.
This doesn't affect system functionality, but somewhat reduces the
reliance on complicated hardcoded paths. It also allows the user to
simply link /init (which is normally a symbolic link) to another program
to run it instead of SystemServer as the default option.
We could technically copy the dynamic loader to other path and run it
from there, so let's not assume paths.
If the user is so determined to do such thing, then a warning is quite
meaningless.
When we run directly the dynamic loader, we shouldn't rely on the passed
program path to be run, but rather on whether the main program fd number
is not -1, because the kernel will set it to a non-negative number if it
exists.
To test that the heuristic is working correctly, the /usr/lib/Loader.so
file can be copied to /tmp/Loader.so and then be invoked from that path.
The dynamic loader can't reasonably run static-pie ELF. static-pie ELFs
might run executable code that invokes syscalls outside of the defined
syscall memory executable (code) region security measure we implement.
Known examples of static-pie ELF objects are ELF packers, and the actual
system-provided dynamic loader itself.
When writing to /sys/kernel/request_panic it will do a kernel panic.
Trying to truncate the node will result in kernel panic with a slightly
different message.
This will allow us to generate code that handle and provide easy access
to metadata stored in TIFF's tags. The generator is a Python script, and
it output both TIFFMetadata.h and TIFFTagHandler.cpp files.
The generator will definitely need some update to support all TIFF and
EXIF tags, but that will still be easier than writing everything
ourselves.
Some small modifications are needed in TIFFLoader.cpp to make it
compatible with the new `Metadata` class.
Page 1 of 0000277.pdf does:
BT 22 0 0 22 59 28 Tm /TT2 1 Tf
(Presented at Photonics West OPTO, February 17, 2016) Tj ET
BT 32 0 0 32 269 426 Tm /TT1 1 Tf
(Robert W. Boyd) Tj ET
BT 22 0 0 22 253 357 Tm /TT2 1 Tf
(Department of Physics and) Tj ET
BT 22 0 0 22 105 326 Tm /TT2 1 Tf
(Max-Planck Centre for Extreme and Quantum Photonics) Tj ET
Every line begins a text operation, then updates the font matrix,
selects a font (TT2, TT1, TT2, TT1), draws some text and ends the text
operation.
`Tm` (which sets the font matrix) contains a scale, and uses that
to update the font size of the currently-active font (cf #20084).
But in this file, we `Tm` first and `Tf` (font selection) second,
so this updates the size of the old font. So when we pull it out
of the cache again on line 3, it would still have the old size
from the `Tm` on line 2.
(The whole text scaling logic in LibPDF imho needs a rethink; the
current approach also causes issues with zero-width glyphs which
currently lead to divisions by zero. But that's for another PR.)
Fixes another regression from c8510b58a3 (which I've accidentally
referred to by 2340e834cd in another commit).
Before this change, every repaint required a glyph atlas update, which
took 10-20% of the total painting time according to my testing on
different websites. This change improves that significantly by skipping
atlas updated when all glyphs are already present in the texture.
