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.
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 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.
As noted in the prototype comments, this implementation becomes less
accurate as the precision approaches the limit of 100. For example:
(3).toPrecision(100)
Should result in "3." followed by 99 "0"s. However, due to the loss of
accuracy in the floating point computations, we currently result in
"2.9999999...".
