The new algorithm is an iterative one with an arbitrary threshold for splitting
curves. It splits curves evenly. This should theoretically be less accurate
than the existing recursive approach, but seems to give subjectively better
results in practice.
I'm planning to make this a minimal-allocation TTF parser. This will
speed up start-up time for applications, but have some overhead for
rasterizing glyphs. Which should be okay, since rasterized glyph bitmaps
should be cached anyway.
This commit just adds the loading of the HEAD table.
This was causing WindowServer and Taskbar to crash sometimes when the
stars aligned and we tried cutting off a string ending with "..." right
on top of an emoji. :^)
Let's just say no to shenanigans by capping images at 16384 pixels both
wide and tall. If a day comes in the future where we need to handle
images larger than this, we can deal with it then.
It was possible to go outside the interlacing row strid/offset arrays.
Just fail the decode if this is about to happen. I've added a FIXME
about rejecting such images earlier, since it's a bit sad to only do
this once we realize the pass index is about to overflow.
Found by oss-fuzz: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28239
Problem:
- Functions are duplicated in [PBM,PGM,PPM]Loader class
implementations. They are functionally equivalent. This does not
follow the DRY (Don't Repeat Yourself) principle.
Solution:
- Factor out the common functions into a separate file.
- Refactor common code to generic functions.
- Change `PPM_DEBUG` macro to be `PORTABLE_IMAGE_LOADER_DEBUG` to work
with all the supported types. This requires adding the image type to
the debug log messages for easier debugging.
Problem:
- `Streamer` is the same in [PBM,PGM,PPM]Loader class implementations.
Solution:
- Extract it to its own header file to reduce maintenance burden.
- Implement `read` in terms of `read_bytes` to make the class "DRY".
- Decorate all functions with `constexpr`.
Problem:
- `(void)` simply casts the expression to void. This is understood to
indicate that it is ignored, but this is really a compiler trick to
get the compiler to not generate a warning.
Solution:
- Use the `[[maybe_unused]]` attribute to indicate the value is unused.
Note:
- Functions taking a `(void)` argument list have also been changed to
`()` because this is not needed and shows up in the same grep
command.
This patchset fixes:
- Some parts of the path being skipped and not drawn (often horizontal)
- The filled shape moving around on an int grid depending on the winding
number
- Winding number mess-up with four-way intersections
Remove ACCURATE_GAMMA_ADJUSTMENT, since it makes the implementation
uglier, isn't guaranteed to make gamma adjustment accurate and is much
slower. gamma_accurate_blend4 should either be always used or not
exist based on compilation flags, so there is no need to have it in
its own function. Finally, we should use AK/SIMD.h instead of defining
our own f32x4 type.
When create_with_shared_buffer() is called in the next line, the
RefPtr::operator* asserts that the RefPtr is not null. That can happen when
we're low-ish on memory, and the image is huge.
Previously, in the case of RLE4, parsing took suspiciously long.
What happened was that 'pixel_count' was 255, and 'i' was incremented
by *two* in each iteration, so the for-loop continued until the
entire output buffer was full, and then rejected the RLE data
as bogus.
This little diff allows pixel_count to reach 256, be greater than
pixel_count, and thus terminate the loop in the intended way.
