Instead of fidgeting with offsets and manually reading out big-endian
values, we now declare the "head" table as a C++ struct and use the
BigEndian<T> template to deal with byte order.
For the ambient light model, integers need to be remapped to a range of
`-1.` through `1.`. Add the `+` and `-` operators to `VectorN` to make
it a bit easier to normalize 4 values at once.
Adapt BMPImageDecoderPlugin to support BMP images included in ICOns.
ICOImageDecoderPlugin now uses BMPImageDecoderPlugin to decode all
BMP images instead of it's own ad-hoc decoder which only supported
32 bpp BMPs.
This could aid debugging in many cases, and it doesn't break any
functionality, so let's ensure it's easier to understand in which way a
provided value is out of range.
This patch introduces error propagation to Gfx::SystemTheme to remove
instances of release_value_but_fixme_should_propagate_errors().
Userland applications that have been affected by this change have been
updated to utilise this propagation and as a result 4 such instances of
the aforementioned method have been removed.
The existing try_create_from_serialized_byte_buffer function accepts a
ByteBuffer, but in reality it requires only a ReadonlyBytes, since
internally the only thing it does is calling buffer.bytes(). There is
thus no reason to have a function that simply accepts ReadonlyBytes, and
implement the former in terms of the newer.
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.
