In one case we can replace it with MUST() and accept the crash (we also
VERIFY() that there wasn't an exception); in the other case we don't
need to return after a throw completion.
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.
