Skia painter is visibly faster than LibGfx painter and has more complete
CSS transforms support. With this change:
- On Linux, it will try to use Vulkan-backend with fallback to
CPU-backend
- On macOS it will try to use Metal-backend with fallback to
CPU-backend
- headless-browser always runs with CPU-backend in layout mode
This change adds a `--use-lagom-networking` flag to the WebWorker
process. Qt networking is used if this flag isn't passed. The flag is
passed the UI launches the WebWorker process unless the Qt chrome is
being run with the `--enable-qt-networking` flag.
GPU painter that uses AccelGfx is slower and way less complete compared
to both default Gfx::Painter and Skia painter. It does not make much
sense to keep it, considering Skia painter already uses Metal backend on
macOS by default and there is an option to enable GPU-accelerated
backend on linux.
This large commit also refactors LibWebView's process handling to use
a top-level Application class that uses a new WebView::Process class to
encapsulate the IPC-centric nature of each helper process.
This was only put in place because on SerenityOS, we wanted to use the
pid of the WebContent process, rather than the peer pid for the socket.
When launching with SystemServer, this got annoying. However, now that
we only have the case that the UI process spawns processes, we can
get rid of this hack. This restores the ability to see WebContent
processes' statistics in the task manager widget.
This is the same behavior as RequestServer, with the added benefit that
we know how to gracefully reconnect ImageDecoder to all WebContent
processes on restart.
Allows WebContentClient to get pid of WebContent process right after
creation, so there is no window between forking and
notify_process_information() IPC response, when client doesn't know the
pid.
This patch adds a simple in-memory HTTP cache to each WebContent
process.
It's currently off by default (turn it on with --enable-http-cache)
since the validation logic is lacking and incomplete.
This adds a `--experimental-cpu-transforms` option to Ladybird and
WebContent (which defaults to false/off).
When enabled the AffineCommandExecutorCPU will be used to handle
painting transformed stacking contexts (i.e. stacking contexts where
the transform is something other than a simple translation). The regular
command executor will still handle the non-transformed cases.
This is hidden under a flag as the `AffineCommandExecutorCPU` is very
incomplete now. It missing support for clipping, text, and other basic
commands. Once most common commands have been implemented this flag
will be removed.
This broke due to the way we now use posix_spawn under the hood. This
moves the handling of the callgrind option to the launcher helper where
we iterate over the candidate process paths, as we need to augment the
way we fork the process for callgrind based on those paths.
This also opens the door for running other processes under callgrind in
the future.
It previously resided in LibWebView to hide the details of launching a
singleton process. That functionality now lives in LibCore. By moving
this to Ladybird, we will be able to register the process with the task
manager.
Sometimes I like to play around with running Ladybird tests using full
blown Ladybird instead of just headless browser to interactively mess
around with the test page. One problem with this is that the internals
object is not exposed in this mode.
This commit supports this usecase by adding an option to specifically
expose the internals object without needing to run headless-browser
in test mode.
When launched with the new --enable-idl-tracing option, we now log
every call to web platform APIs declared via IDL, along with the
arguments passed.
This can be very helpful when trying to figure out what a site is
doing, especially if it's not doing what you'd expect.
When running with --log-all-js-exceptions, we will print the message
and backtrace for every single JS exception that is thrown, not just
the ones nobody caught.
This can sometimes be very helpful in debugging sites that swallow
important exceptions.
On Serenity, it's not trivial to extract the peer pid from a socket that
is created by SystemServer and then passed to a forked service process.
This patch adds an API to let the WebContent process notify the UI
directly, which makes the WebContent process show up in the Serenity
port's TaskManagerWidget. It seems that we will need to do something of
this sort in order to properly gather metrics on macOS as well, due to
the way that self mach ports work.
Instead of spawning these processes from the WebContent process, we now
create them in the Browser chrome.
Part 1/N of "all processes are owned by the chrome".
It is currently a bit messy to pass these options along from main() to
where WebContent is actually launched. If a new flag were to be added,
there are a couple dozen files that need to be updated to pass that flag
along. With this change, the flag can just be added to the struct, set
in main(), and handled in launch_web_content_process().
This patch brings a service to handle image decompression. With it comes
security enhancement due to the process boundary. Indeed, consequences
of a potential attack is reduced as only the decoder will crash without
perturbing the WebContent process.
It also allows us to display pages containing images that we claim to
support but still make us crash, like for not-finished-yet decoders.
As an example, we can now load https://jpegxl.info/jxl-art.html without
crashing the WebContent process.
We were super inconsistent about this, with most "new" classes living in
the Ladybird namespace, while "old" ones were in the global namespace,
or even sitting in the Browser namespace.
LibTLS still can't access many parts of the web, so let's hide this
behind a flag (with all the plumbing that entails).
Hopefully this can encourage folks to improve LibTLS's algorithm support
:^).
Re-organize our helper files here a bit, to make a clearer distinction
between Qt-specific helpers and generic non-serenity helpers.
A future commit will move Lagom specific code from LibSQL to ladybird
as well, so that we can see about future generic apis for spawning
helper procesess.
The spawn_helper_process method was introduced together with
get_paths_for_helper_process but was only ever used briefly to spawn
WebContent. Other helper processes (SqlServer, headless_browser etc)
are either execed or spawned with their own helpers & custom arguments.
Currently, we only look at the relative path `./{helper}/{helper}`,
which fails if the working directory is not the same as the directory
where the ladybird binary lives.
