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.
- OSv2 DIBs were not checked at all
- Regular Info DIBs had the compression checked after applying a 0xFF mask,
which let many invalid compression values pass.
- There may still be a separate latent bug that causes mask_sizes and mask_shifts to be empty.
This is a hack which can be removed once GitHub Actions changes the
default version to clang 11.
This is apparently sometime in mid-December.
Note, clang-11 is not currently available on Ubuntu 20.04. However,
GitHub Actions uses 20.04, which probably means clang-11 will
become available around that time for all 20.04 users.
The JPEG spec allows component IDs to be chosen arbitrarily from the
interval [0, 255]. Storing components in a vector corrupts the decoder
when component IDs are not in the range 0-3. Normally, encoders don't
use IDs outside of that range because JPEG doesn't support more than
4 channels. But since there is a chance that a spec compliant JPEG
would have component IDs outside of [0-3], we should consider replacing
the vector, which enforces serial component access based on component
IDs, with a HashMap<u8, ComponentSpec>.
Switch over to gamma-aware interpolation. This causes color gradients
to not look so dark in the middle. SIMD optimized code is provided for
sse1 enabled builds.
Fixes#1342.
This doesn't fix all the issues found by the fuzzer, but it fixes
many of them. When running this
Meta/Lagom/Fuzzers/FuzzJPGLoader -jobs=24 -workers=24 \
../Base/res/html/misc/jpgsuite_files/
for 10 minutes on my machine, the fuzzer foudn 2 crashers, but after
this change it finds just ... 2. But with different stacks!
This just fixes ASSERT()s, so it's not security critical, but
ASSERT()s still crash the programs decoding JPGs, and crashing
less is nice even if it's not a security concern.
Bitmap::is_path_a_supported_image_format() and Bitmap::load_from_file()
now check the file extension with CaseSensitivity::CaseInsensitive.
This fixes a couple of inconsistencies, for example would
FileSystemModel::icon_for() recognize image files uppercase extensions
but couldn't create thumbnails for them (any attempt to create a bitmap
from such files would fail).
If we try to read a sentinel byte but the stream is fresh out of data,
we have to take care of the stream error and bail out right away, or
we'll hit an assertion when exiting the function soon after.
Fixes#3486.
GIFLoader now tracks the state of errors during the decoding process
and will fall back to displaying the first frame of the GIF if any of
the subsequent frames fail to decode.
