Callbacks registered within the SharedImageRequest can be removed after
the request has been completed. This resolves the GC memory leak issue
that occurs due to a cyclic dependency, where the callback captures the
image request while being owned by the image request at the same time.
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.
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.
This allows to partially solve the problem of cyclic dependency between
HTMLImageElement and SharedImageRequest that prevents all image
elements from being deallocated.
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.
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).
On Serenity and on my Linux machine, we have a 1:1 CSS-to-device pixel
ratio. On macOS, we have a 2:1 ratio. This did not affect the Qt chrome,
because we are ignoring this position and placing the context menu at
the globally-accessible mouse position. The AppKit chrome will be using
this position, though.
This might be what caused the issue worked around by commit 8177ecb.
Having all 4 of these methods together makes it more immediately obvious
that the 2 moved here are not correct (we are not converting the CSS
pixel point to a device pixel point).
When a box is sized under max-content constraint, any percentage value
set for max-width should be considered as if it were infinite. In other
words, it should have no effect on restricting the box's width.
This effectively makes it per-Document, but we hang it off of
StyleComputer since that's what it's used for.
The purpose of this is to prevent downloaded fonts from escaping the
context that loaded them. There's probably a more elegant solution where
we still share caching of system fonts, but let's start here.
This change introduces a very basic GC graph dumper. The `dump_graph()`
function outputs JSON data that contains information about all nodes in
the graph, including their class types and edges.
Root nodes will have a property indicating their root type or source
location if the root is captured by a SafeFunction. It would be useful
to add source location for other types of roots in the future.
Output JSON dump have following format:
```json
"4908721208": {
"class_name": "Accessor",
"edges": [
"4909298232",
"4909297976"
]
},
"4907520440": {
"root": "SafeFunction Optional Optional.h:137",
"class_name": "Realm",
"edges": [
"4908269624",
"4924821560",
"4908409240",
"4908483960",
"4924527672"
]
},
"4908251320": {
"class_name": "CSSStyleRule",
"edges": [
"4908302648",
"4925101656",
"4908251192"
]
},
```
This doesn't seem to actually have fixed any bugs, as having
FillOpacity instead of StrokeOpacity in the call to parse_css_value
doesn't seem to have actually been causing bugs. But, I still think it's
worthwhile correcting.
The reason that it wasn't causing bugs is that having FillOpacity
instead of StrokeOpacity in the call to parse_css_value means that when
parsing the value is compared to the acceptable values for that property
(for example the value can only be a percentage, or a number, etc.). In
this case both FillOpacity and StrokeOpacity seem to accept the same
values.
The SVG G container should have the same size as its children. This
fixes a bug when there was an opacity value on the G element, as in
StackingContext it would try and get a bitmap of the element which would
be empty due to it having no size.
