In a bunch of cases, this actually ends up simplifying the code as
to_number will handle something such as:
```
Optional<I> opt;
if constexpr (IsSigned<I>)
opt = view.to_int<I>();
else
opt = view.to_uint<I>();
```
For us.
The main goal here however is to have a single generic number conversion
API between all of the String classes.
With this change, chrome no longer has to ask the WebContent process
to paint the next frame into a specified bitmap. Instead, it allocates
bitmaps and sends them to WebContent, which then lets chrome know when
the painting is done.
This work is a preparation to move the execution of painting commands
into a separate thread. Now, it is much easier to start working on the
next frame while the current one is still rendering. This is because
WebContent does not have to inform chrome that the current frame is
ready before it can request the next frame.
Additionally, as a side bonus, we can now eliminate the
did_invalidate_content_rect and did_change_selection IPC calls. These
were used solely for the purpose of informing chrome that it needed to
request a repaint.
While it would be more hygienic to get a fresh Navigable each time,
loading `about:blank` still means we discard the current Document.
This does noticeably increase the duration of running the LibWeb test
suite. On my machine, we go from ~5.5 seconds to ~7.7.
Calling test() multiple times in the same test file is not actually
valid, and can cause the following test to hang forever. So let's stop
doing that in the one test that did so, and also prevent the same
mistake happening again. :^)
Throwing an exception on subsequent test() calls means that we don't
hang, the test will fail with missing output, and we get a log message
explaining why.
This caused a dangling reference down the line, which lead to funny
things like the following:
> cd Bui[tab]
> cd Bui^@^@
By returning a direct reference to the suggestion in question, we can be
sure that the referenced object is alive until the next suggestion
cycle.
Half the functions used are not readily available on windows, instead of
creating more ifdef soup, this commit simply disables the rich debug
stuff on windows.
Our existing AnonymousVMObject cloning flow contains an optimization
wherein purgeable VMObjects which are marked volatile during the clone
are created as a new zero-filled VMObject (as if it was purged), which
lets us skip the expensive COW process.
Unfortunately, one crucial part was missing: Marking the cloned region
as purged, (which is the value returned from madvise when unmarking the
region as volatile) so the userland logic was left unaware of the
effective zero-ing of their memory region, resulting in odd behaviour
and crashes in places like our malloc's large allocation support.
This is a pretty straightforward test, but I managed to make this crash
on real sites while trying to fix#20971 without any other test in the
existing suite failing.
UnassociatedAlpha is the one used by GIMP when generating TIFF images
with transparency. Support is added for Grayscale and RGB images as it's
the two that we support right now but managing transparency should be
really straightforward for other types as well.
If we don't have __builtin_add_overflow_p(), we can also try using
__builtin_add_overflow(). This makes debug builds with Clang
significantly faster since they no longer need to use the generic
implementation. Same for multiplication.
Before this change, it was possible for a text test to finish before
on_load_finish() was triggered, resulting in the subsequent test
receiving the load event from the previous test.
This lets us fail early at configure time if a suitable Python 3
interpreter is not present, instead of delaying the error until Ninja
attempts to run `embed_as_string_view.py` to generate a header in the
middle of the build.
Refs #21791
The idea is to massage the inline image data into something that
looks like a regular image, and then use the normal image drawing code:
We translate the inline image abbreviations to the expanded version at
rendering time, then unfilter (i.e. uncompress) the image data at
rendering time, and the go down the usual image drawing path.
Normal streams are unfiltered when they're first accessed, but
inline image streams live in a page's drawing operators, and this
fits the current approach of parsing a page's operators anew
every time the page is rendered.
(We also need to add some special-case handling for color spaces
of inline images: Inline images can use named color spaces, while
regular images always use direct color space objects.)
This is to allow future changes to do cross-process MessagePorts in an
implementation-agnostic way. Add some tests for this behavior.
Delivering messages that were posted to a MessagePort just before it was
transferred is not yet implemented still.
