PNGWriter sets up one dummy scanline with the same width as the other
scanlines in order to allow addressing the "previous scanline" without
complicating the code.
By using a FixedArray instead of a VLA, we sidestep the risk of stack
overflow and instead get something that can signal OOM.
This patch basically uses the TRY() macro throughout PNGWriter instead
of relying on the MUST()'ing wrappers in Vector and ByteBuffer.
One FIXME was killed in the making of this patch. :^)
This is a first step towards handling PNG encoding failures instead of
just falling over and crashing the program.
This initial step will cause encode() to return an error if the final
ByteBuffer copy fails to allocate. There are more potential failures
that will be surfaced by subsequent commits.
Two FIXMEs were killed in the making of this patch. :^)
Without this change, the upcoming LibWeb pixel types will require a
silly doubled conversion in some places.
eg: `some_rect.to_type<int>().to_type<float>()`
With these overloads, we can get away with `some_rect.to_type<int>()`.
Gfx::Color is always 4 bytes (it's just a wrapper over u32) it's less
work just to pass the color directly.
This also updates IPCCompiler to prevent from generating
Gfx::Color const &, which makes replacement easier.
This will make it easier to support both string types at the same time
while we convert code, and tracking down remaining uses.
One big exception is Value::to_string() in LibJS, where the name is
dictated by the ToString AO.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
Turns out most things expect lines to include the endpoint,
e.g. 0,0 -> 3,0 is a 4px long line. But the fill_path() implementation
seems to expect the line to be the distance between the two points
(so the above example is a 3px line instead).
This now adds an option to pick between PointToPoint line length or
Distance line length and uses the latter for fill_path().
m_rotated_rectangle_path was unused and m_intersection_edge_path was
cleared/free'd each time it was used. So sticking in the class just
bloats the size.
This gives a slightly more reasonable result when comparing different
colors with low alpha values.
For example comparing white with alpha 100 to transparent:
Before
distance: 0.78
After
distance: 0.07
(Where distance is between 0 and 1)
The result is unchanged for comparing colors without alpha values.
The main fix is stopping fill_path() scanlines being rounded to the
wrong pixel. The y-value is now floored to ensure it always snaps
in the same direction.
Also, add `Line::to_type<T>()` since that was missing.
Calling to_type() with the same type as the existing object accomplishes
nothing except wasting some cycles and making the code more verbose,
and it is hard to spot. Nobody does this in the code currently
(yay!) but I made this mistake repeatedly when doing my step-by-step
CSS Pixels conversion, so let's make it easier to catch them.
draw_line_for_path() is the same as the standard antialiased
draw_line() but with a few few small hacks to improve the look of
paths.
AntiAliasPolicy is also removed as it's now unused.
This is not any 'proper' algorithm, this was just a shower thought
idea. There probably is a better algorithm to achieve the same effect
out there, if someone knows of one please replace this code :^).
This works by rendering the line a scanline at a time, which avoids
repainting over any pixel on the line (so opacity now works with AA
lines). This generally seems to achieve a much nicer looking line.
I've not done any proper benchmarking of this, but some little messing
around showed that this new implementation was a little faster than
the old one too, so that's a nice little bonus.
With the inclusion of a few minor hacks this also goes a surprisingly
far way in improving our SVG rendering too (for both filled and stroked
paths). :^)
The custom TTF path rasterizer is actually generic enough for it to be
used for other fonts. To make this more clear, it now lives on its own
in the "Font" directory.
This patch optimizes the drawing of aa-lines by rotating the drawn
rectangle to the direction where the line points. That enables us to
draw non-straight lines with the proper width.
If a aa-line is drawn that is infact a straigt line we now dont plot
those lines with multipe rectangles across the line - insted we draw
straight lines in one go with just one rectangle of proper size.
Stroking of lines has been enhanced to take care of the edges between
two lines with drawing the stroke till the intersections of two
connected lines.
In order to avoid the base encode/decode methods from being used (and
failing a static assertion), we must be sure to declare/define the
custom type implementations as template specializations.
After this, LibIPC is no longer sensitive to include order.
This table seems to only exist for OpenType compatibility. There are
some font files, including most embedded fonts in PDF documents, that
don't include one.
For those cases, we now just zero-initialize one to the largest
supported size.
C++20 can automatically synthesize `operator!=` from `operator==`, so
there is no point in writing such functions by hand if all they do is
call through to `operator==`.
This fixes a compile error with compilers that implement P2468 (Clang
16 currently). This paper restores the C++17 behavior that if both
`T::operator==(U)` and `T::operator!=(U)` exist, `U == T` won't be
rewritten in reverse to call `T::operator==(U)`. Removing `!=` operators
makes the rewriting possible again.
See https://reviews.llvm.org/D134529#3853062
This PR adds resize ability to PixelPaint as per issue 11862.
The previous behaviour was to always rescale the canvas when
resizing an image. This adds a checkbox to toggle between
rescaling, and resizing which blits the existing canvas to
the top left of the new, resized canvas.
As part of this, a new ScalingMode is added to
LibGfx - None.
Otherwise, we end up propagating those dependencies into targets that
link against that library, which creates unnecessary link-time
dependencies.
Also included are changes to readd now missing dependencies to tools
that actually need them.
This allows the copy constructor of Matrix to be called constexpr,
which should allow more values to be compile-time calculated.
Likewise, VectorN.data() is now constexpr so that it can be compile-time
evaluated.
The implementations for these methods is manually defined in the .cpp
file for `int` and `float`, meaning that other `T` values would fail -
but only once we got to the linking stage. This patch makes the error
happen much earlier, so it's more obvious.
Putting the implementations in the .cpp file meant that they only
existed for `IntRect` and `FloatRect`, since those were instantiated at
the bottom of the file. Now they work for other types. :^)
A couple of places in WindowServer had to be modified to disambiguate
between the two `Rect::intersected()` overloads.
Co-authored-by: davidot <davidot@serenityos.org>
This change implements a flood fill algorithm for the Bitmap class. This
will be leveraged by various Tools in PixelPaint. Moving the code into
Bitmap reduces the duplication of the algorithm throughout the
PixelPaint Tools (currently Bucket Tool and Wand Select).
The flood fill function requires you to pass in a threshold value (0 -
100) as well as a lambda for what to do when a pixel gets reached. The
lambda is provided an IntPoint representing the coordinates of the pixel
that was just reached.
The genericized lambda approach allows for a variety of things to be
done as the flood algorithm progresses. For example, the Bucket Tool
will paint each pixel that gets reached with the fill_color. The Wand
Select tool wont actually alter the bitmap itself, instead it uses the
reached pixels to alter a selection mask.
