Currently, disabled text colors are hardcoded. They look good in Default
and light themes, but no so good in dark ones. This PR adds new
variables for all themes to correctly display disabled text.
This matches the rename of RGBA32 to ARGB32. It also makes more sense
when you see it used with 32-bit hexadecimal literals:
Before:
Color::from_rgba(0xaarrggbb)
After:
Color::from_argb(0xaarrggbb)
The ARGB32 typedef is used for 32-bit #AARRGGBB quadruplets. As such,
the name RGBA32 was misleading, so let's call it ARGB32 instead.
Since endianness is a thing, let's not encode any assumptions about byte
order in the name of this type. ARGB32 is basically a "machine word"
of color.
`CharacterBitmap` instances are generated at run-time and put on the
heap, but they can be created in a `constexpr` context and stored in
static memory.
Also, remove additional `width` and `height` `static` values in favor
of using the `constexpr` member functions of `CharacterBitmap`.
These changes also include the removal of some initialization code
which tests if the `CharacterBitmap` is created since it is always
created and removes function-local `static` values which cause
run-time branches to ensure it is initialized each time the function
is called.
There is nothing in the `Size` class which cannot be `constexpr`, but
without it being `constexpr` it prevents other things from being
`constexpr`-capable.
`Gfx::Vector[2,3,4]` are nearly identical implementations. This code
redundancy does not follow the DRY (Don't Repeat Yourself) principle
leading to possible out-of-sync errors between the classes.
Combining these classes into a class template which can be specialized
for each needed size makes the differences obvious through
`constexpr-if` blocks and `requires` clauses.
This allows bitmap font lookup to return the best matching size instead
of failing completely. The previous behavior (exact matches only)
remains the default.
This shape is for use by the main widget of a frameless window
that still wishes to have proper borders but no title.
Raised Containers were used previously for this pattern but did not
always represent perspective and shadow correctly depending on thread
highlighting and the immediate background color. Containers are
really meant to be used inside other widgets where the background
color can be controlled.
Fonts now provide their preferred line height based on maximum
height and requested line gap. TTFs provide a preferred line gap
from table metrics while BitmapFonts are hardcoded at the previous
default for now.
This necessitates switching from passing a single code point to the
callback to passing a non-const Utf8CodePointIterator instead.
Note that the text selection mechanisms in LibGUI and LibWeb don't
handle this properly yet; they still assume that each code point
renders as one glyph. Similarly, width calculations for text widths
don't either, so a single such an emoji will require space for more
than one glyph.
It also doesn't work in LibVT's TerminalWidget, where each code point
is handled and rendered separately, so LibGfx never gets a chance to
check if subsequent code points could result in a combined emoji.
In the common case of text rendering rather than getting the emoji
bitmap for a fixed number of code points, we don't know how many code
points make one emoji. As far as I can tell, the longest ones are up to
ten code points, so we try to consume all of them and do a lookup during
each iteration, and return the emoji for the longest chain of code
points. Quite basic and definitely room for improvement, but it works!
Not all emojis are just one code point, so the existing API is not
sufficient: Emoji::emoji_for_code_point(u32).
The file name for such emojis is simply each U+XXXX separated by an
underscore.
Some grayscale JPG images might have the horizontal and vertical sample
factor set to 2. However, the macroblocks in these images are not
interleaved as they would be in color images.
I've attempted to handle the errors gracefully where it was clear how to
do so, and simple, but a lot of this was just adding
`release_value_but_fixme_should_propagate_errors()` in places.
For PNG color type 2 (TrueColor), if there's a tRNS chunk, it specifies
an R/G/B triplet in the image bit depth. This triplet acts as the
transparency value, and should yield transparent pixels wherever that
specific color value is present.
We now support this. :^)
The tRNS metadata is valid for color types 0, 2 and 3, so let's collect
it in each of those cases.
This ensures that we produce a bitmap with an alpha channel if needed.
This method is commonly used by bitmap text rendering. Adding support
for color blending enables support in the browser for text opacity using
their color property.
Gamma.h includes xmmintrin.h, which is X86-only. The file contains
code in other places that is compiled conditionally on __SSE__, so the
same macro is used to determine inclusion of the header.
This returns a more comprehensible name than raw weight and slope
metrics and is intended for use in UIs. Now displays human readable
font names in FontSettings, TerminalSettings and CharacterMap.
In order to avoid having multiple instances, we were keeping a pointer
to these singleton objects and only allocating them when it was null.
We have `__cxa_guard_{acquire,release}` in the userland, so there's no
need to do this dance, as the compiler will ensure that the constructors
are only called once.
Apologies for the enormous commit, but I don't see a way to split this
up nicely. In the vast majority of cases it's a simple change. A few
extra places can use TRY instead of manual error checking though. :^)
This patch adds support for drawing triangular waves.
For now those can only be horizontal, but as they are intended for
underlining text, it's an okay way to handle this.
The two Adler32 checksums are u16 and these two getters were mistakenly
left as u32 when PNGChunk::add_as_big_endian() was templated leading
to corrupted IDAT fields in our PNGs.
Allow `Matrix::inverse()` to return an error and deal with those in
LibGL. Also use this opportunity to more efficiently calculate the
transpose of the model view matrix for the normal transformation.
