The proper syntax for defining user-defined literals does not require a
space between the `operator""` token and the operator name:
> error: identifier 'sv' preceded by whitespace in a literal operator
> declaration is deprecated
In FetchAlgorithms, it is common for callbacks to capture realms. This
can indirectly keep objects alive that hold FetchController with these
callbacks. This creates a cyclic dependency. However, when
JS::HeapFunction is used, this is not a problem, as captured by
callbacks values do not create new roots.
This change introduces HeapFunction, which is intended to be used as a
replacement for SafeFunction. The new type behaves like a regular
GC-allocated object, which means it needs to be visited from
visit_edges, and unlike SafeFunction, it does not create new roots for
captured parameters.
Co-Authored-By: Andreas Kling <kling@serenityos.org>
This is a minimal set of changes to allow `serenity.sh build riscv64` to
successfully generate the build environment and start building. This
includes some, but not all, assembly stubs that will be needed later on;
they are currently empty.
The setup is a bit peculiar: both the definition and the use site of
these TLS variables have to be in a shared library, otherwise the linker
might relax the global-dynamic access mode to something that doesn't
require a `__tls_get_addr` call.
This is a prerequisite for upstreaming our LLVM patches, as our current
hack forcing `-ftls-model=initial-exec` in the Clang driver is not
acceptable upstream.
Currently, our kernel-managed TLS implementation limits us to only
having a single block of storage for all thread-local variables that's
initialized at load time. This PR merely implements the dynamic TLS
interface (`__tls_get_addr` and TLSDESC) on top of our static TLS
infrastructure. The current model's limitations still stand:
- a single static TLS block is reserved at load time, `dlopen()`-ing
shared libraries that define thread-local variables might cause us to
run out of space.
- the initial TLS image is not changeable post-load, so `dlopen()`-ing
libraries with non-zero-initialized TLS variables is not supported.
The way we repurpose `ti_module` to mean "offset within static TLS
block" instead of "module index" is not ABI-compliant.
LibC is always guaranteed to be loaded at program start, so its
thread-local variables live in the static TLS block. This permits us to
use the more optimal initial-exec TLS access model.
Shadow doorbell feature was added in the NVMe spec to improve
the performance of virtual devices.
Typically, ringing a doorbell involves writing to an MMIO register in
QEMU, which can be expensive as there will be a trap for the VM.
Shadow doorbell mechanism was added for the VM to communicate with the
OS when it needs to do an MMIO write, thereby avoiding it when it is
not necessary.
There is no performance improvement with this support in Serenity
at the moment because of the block layer constraint of not batching
multiple IOs. Once the command batching support is added to the block
layer, shadow doorbell support can improve performance by avoiding many
MMIO writes.
Default to old MMIO mechanism if shadow doorbell is not supported.
Introduce a new Struct Doorbell that encapsulates the mmio doorbell
register.
This commit does not introduce any functional changes and it is added
in preparation to adding shadow doorbell support.
This allows to partially solve the problem of cyclic dependency between
HTMLImageElement and SharedImageRequest that prevents all image
elements from being deallocated.
This was the root cause of zombie processes showing up randomly and
disappearing after some disk activity, such as running shell commands -
The NVMeIO AsyncBlockDeviceRequest member simply held a pointer to a
Process object, therefore it could keep it alive a for a long time after
it ceased to actually function at all.
This patch adds three new modes to the brush-tool where it is now
possible to use a dodge or burn function with the brush and a soft mode
where the overdraw is reduced so that the stroke looks much softer.
The dodge and burn functions are used to brighten or darken the colors
in the affected area of the brush. The user can decide if the
highlights, midtones or shadows should be prioritized by the brush.
This patch optimizes how the Brush-Tool modifies the pixels. The new
logic generates a "reference brush" with the required size, falloff
and color only once and uses that for the rawing operations. If no
editing mask is used the reference brush is writen via a blit operation
to the content or mask image. This increases the drawing speed and
therefore also allows bigger brush sizes.
This patch allows a bigger brush tool size of 250 pixels and limits the
cursor bitmap to a reasonable size so that its not much bigger than the
image editor size. If the cursor is bigger as the editor it is rended
with a red edge to indicate that the actual cursor is bigger than
displayed. This change mitigates the OOM conditions when the cursor
gets unusual big.
This has to cheat and use a screenshot but thanks to the "Take Full
Screenshot" feature of Ladybird, it is very easy to update this test.
The steps are documented in the test.
These were added when Gfx::Rect was made endpoint exclusive, however,
for this code an offset of ±1 makes no visible difference (but makes the
code look a little confusing).
