Using mmap-allocated memory for backing stores does not allow us to
benefit from using GPU-accelerated painting, because all the performance
increase we get is mostly negated by reading the GPU-allocated texture
back into RAM, so it can be shared with the browser process.
With IOSurface, we get a framebuffer that is both shareable between
processes and can be used as underlying memory for an OpenGL/Metal
texture.
This change does not yet benefit from using IOSurface and merely wraps
them into Gfx::Bitmap to be used by the CPU painter.
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.
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.
In the upcoming changes, we are going to switch macOS to using an
IOSurface for the backing store. This change will simplify the process
of sharing an IOSurface between processes because we already have the
MachPortServer running in the browser, and WebContent knows how to
locate the corresponding server.
This change ensures that if a screenshot is requested between teardown
of paintable tree and relayout, we will wait for layout to complete
before taking a screenshot.
LibLocale was split off from LibUnicode a couple years ago to reduce the
number of applications on SerenityOS that depend on CLDR data. Now that
we use ICU, both LibUnicode and LibLocale are actually linking in this
data. And since vcpkg gives us static libraries, both libraries are over
30MB in size.
This patch reverts the separation and merges LibLocale into LibUnicode
again. We now have just one library that includes the ICU data.
Further, this will let LibUnicode share the locale cache that previously
would only exist in LibLocale.
We only need LibCoreMinimal for the lagom-tools build. In particular, by
removing LibUnicode, we remove the lagom-tools dependence on the system
ICU package, as we do not have vcpkg hooked into this build. (We could
probably add vcpkg here, but since this libraries aren't even needed, we
don't need to bother).
When any LibCore file (or any of its dependents) changes, we have to
regenerate all IDL bindings. By depending on LibCoreMinimal, the number
of impacting files greatly reduces.
As an example, changing a .cpp file in LibUnicode would previously cause
about 1800 ninja targets to rebuild. This is now reduced to about 200.
If a flex item has a preferred aspect ratio and the flex basis is not
definite, we were falling back to using stretch-fit for the main size,
since that appeared to match other browsers.
However, we missed the case where we actually have a definite cross size
through which the preferred aspect ratio can be naturally resolved.
Most users will be building with Xcode Clang on macOS anyway, as our
build scripts default to the system compiler if it's new enough. We
already have an upstream Clang-based workflow on Linux, so we won't lose
any compiler coverage by switching to Apple Clang on macOS.
This should help us avoid build breakages like #186.
There is no functional change here, but they added an error message to
the install output to indicate what host tools need to be installed.
This has tripped some people up, so it seems worth updating to.
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 implements most of the CloseWatcher API from the html spec.
AbortSignal support is unimplemented.
Integration with dialogs and popovers is also unimplemented.
For SerenityOS, we parse emoji metadata from the UCD to learn emoji
groups, subgroups, names, etc. We used this information only in the
emoji picker dialog. It is entirely unused within Ladybird.
This removes our dependence on the UCD emoji file, as we no longer
need any of its information. All we need to know is the file path to
our custom emoji, which we get from Meta/emoji-file-list.txt.