This brings mmap more in line with other operating systems. Prior to
this, it was impossible to request memory that was definitely committed,
instead MAP_PURGEABLE would provide a region that was not actually
purgeable, but also not fully committed, which meant that using such memory
still could cause crashes when the underlying pages could no longer be
allocated.
This fixes some random crashes in low-memory situations where non-volatile
memory is mapped (e.g. malloc, tls, Gfx::Bitmap, etc) but when a page in
these regions is first accessed, there is insufficient physical memory
available to commit a new page.
Old font functionality has been moved into BitmapFont
and an abstract Font interface has been introduced to
faciliate further development of TTF font integration.
Compared to version 10 this fixes a bunch of formatting issues, mostly
around structs/classes with attributes like [[gnu::packed]], and
incorrect insertion of spaces in parameter types ("T &"/"T &&").
I also removed a bunch of // clang-format off/on and FIXME comments that
are no longer relevant - on the other hand it tried to destroy a couple of
neatly formatted comments, so I had to add some as well.
We previously had a cached bold variant font in Gfx::Font that was very
haphazardly located by filename pattern. This patches replaces that
mechanism with a proper Gfx::FontDatabase lookup for the same font but
with bold weight (700).
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