This is a temporary mechanism while LibUnicode is in an in-between state
where some symbols are weakly linked and others are dynamically loaded.
The latter require an asm() label to be loaded.
Currently, we load the generated Unicode symbols with dlopen at runtime.
This is unnecessary as of 565a880ce5.
Applications that want Unicode data now link directly against the shared
library holding that data. So the same functionality can be achieved
with weak symbols.
These were missed in 565a880ce5.
This wasn't an issue because these tests don't pledge/unveil anything,
so they could happily dlopen() the library at runtime. But this is now
needed in order to migrate LibUnicode towards weak symbols instead.
This requires an implementation of the "text preparation algorithm" as
specified here:
html.spec.whatwg.org/multipage/canvas.html#text-preparation-algorithm
However, we're missing a lot of things such as the
CanvasTextDrawingStyles interface, so most of the algorithm was not
implemented. Additionally, we also are not able to use a LineBox like
the algorithm suggests, because our layouting infra is not up to the
task yet. The prepare_text function does nothing other than figuring out
the width of the given text and return glyphs with offsets at the
moment.
This is a static helper function for asking the user what they want to
do about unsaved changes. It behaves as a standard Yes/No/Cancel box
with text and buttons tailored to the typical unsaved changes use case.
A bloom filter creates fringes around bright areas in the image
mimicking the behavior of real-world cameras.
It gets its own category "Artistic" in the Filter Gallery since its not
one filter per se but a combination of multiple.
The filter works as follows:
- Get only the light areas (above a threshold) of the image
- Blur that image
- Compose onto the original image
With this BitmapMixer one can draw one Bitmap onto another with
different modes.
For now the only supported mixing methods implemented are Add and
Lightest (which is very naive).
The FastBoxBlurFilter has been living in LibGfx for a while and now
it's accessible in PixelPaint. The parameters for the filter are exposed
via the new Filter Gallery.
1268b39ba introduced template specialization when reading/writing
to/from the bitmap that increased the speed of the filter.
To keep that while supporting more than one BitmapFormat, the
appropriate {get,set}_pixel<>() functions are detemined and stored in
Function<>s.
The first byte of the EBDA structure contains the size of the EBDA
in 1 KiB units. We were incorrectly using the word at offset 0x413
of the BDA which specifies the number of KiB before the EBDA structure.
The `aarch64/t-aarch64` makefile fragment needs to be included for the
aarch64-specific parts of GCC to be built. Before 738e52da5, this was
done implicitly, but now it is not. This caused the following error when
building the toolchain: "aarch64-builtins.o: No such file or directory".
Contradictory to the comment above it, this while loop was actually
clearing the selectors above or equal to the edited one (instead of
the selectors that were skipped when the gdt was extended), this wasn't
really an issue so far, as all calls to this function did extend the
GDT, which meant this condition was always false, but future calls to
this function that will try to edit an existing entry would fail.
The wrong conception that done() would stop the program flow right there
lead to the lambda not properly aborting when no filter was selected.
The ExecAborted would be processed and then the nullptr that was
m_selected_filter would be happily dereferenced.
This patch fixes that.
Now, the filters can supply the Filter Gallery with a GUI::Widget such
that the user can interact with the filter. The Filter Gallery in turn
only calls apply() on the filter once it should be run.
This decouples the PixelPaint filters a lot from the ones supported by
LibGfx and paves the way to filters with settings.
For now there still are just the plain LibGfx filters so this change
feels like introducing a lot of boilerplate, but in the future there
will be a lot more to see.
