I accidentally skipped this part of the spec in the QOI decoder:
> The alpha value remains unchanged from the previous pixel.
This led to incorrect rendering of some images with transparency,
visible in form of a horizontal line of non-transparent pixels (that
shouldn't exist), e.g. for the following chunk sequence:
- QOI_OP_RGBA with alpha = 0
- QOI_OP_RGB
- QOI_OP_RUN
The QOI_OP_RGB should 'inherit' the alpha value of the previous
QOI_OP_RGBA chunk, instead of always setting it to 255.
I'm unsure why the encoder added the QOI_OP_RGB chunk to the specific
image where the bug was noticed in the first place - they effectively
both had fully transparent color values.
This wasn't quite following what the spec says for step 2:
"If index is −1, then remove the last element in the rows collection
from its parent, or do nothing if the rows collection is empty."
It was behaving like:
"If index is −1 and the rows collection is not empty, then remove the
last element in the rows collection from its parent."
Which is not the same, as it will fall into the "Otherwise" if
`index == -1` and the rows collection is empty and try and get the -2nd
element of the rows.
Found with Domato.
Step 1 of the spec is to capture the <script> element's node document
into a local variable.
When I originally implemented this, I thought this was not necessary.
However, I realised that the script that runs can adopt the current
script element into a different document, meaning step 5.4 and 6 then
operate on the incorrect document.
Covered by this WPT: 7b0ebaccc6/html/semantics/scripting-1/the-script-element/moving-between-documents-during-evaluation.html
Previously, we would use lossy strtod() conversion. This was bad,
especially since we switched from internally storing Calculator
state in a double to storing it in the KeypadValue class
some time ago. This commit adds a constructor for the KeypadValue
class that is not lossy by using strtoll(). It handles numbers
with and without decimal points as well as negative numbers
correctly.
In order to reduce our reliance on __builtin_{ffs, clz, ctz, popcount},
this commit removes all calls to these functions and replaces them with
the equivalent functions in AK/BuiltinWrappers.h.
...by flattening the underlying bytecode chunks first.
Also avoid calling DisjointChunks::size() inside a loop.
This is a very significant improvement in performance, making the
compilation of a large regex with lots of alternatives take only ~100ms
instead of many minutes (I ran out of patience waiting for it) :^)
The generated data for libunicodedata.so is quite large, and loading it
is a price paid by nearly every application by way of depending on
LibRegex. In order to defer this cost until an application actually uses
one of the surrounding APIs, dynamically load the generated symbols.
To be able to load the symbols dynamically, the generated methods must
have demangled names. Typically, this is accomplished with `extern "C"`
blocks. The clang toolchain complains about this here because the types
returned from the generators are strictly C++ types. So to demangle the
names, we use the asm() compiler directive to manually define a symbol
name; the caveat is that we *must* be sure the symbols are unique. As an
extra precaution, we prefix each symbol name with "unicode_". For more
details, see: https://gcc.gnu.org/onlinedocs/gcc/Asm-Labels.html
This symbol loader used in this implementation provides the additional
benefit of removing many [[maybe_unused]] attributes from the LibUnicode
methods. Internally, if ENABLE_UNICODE_DATABASE_DOWNLOAD is OFF, the
loader is able to stub out the function pointers it returns.
Note that as of this commit, LibUnicode is still directly linked against
LibUnicodeData. This commit is just a first step towards removing that.
Loading libunicodedata.so will require dlopen(), which in turn requires
mmap(). The 'prot_exec' pledge is needed for this.
Further, the .so itself must be unveiled for reading. The "real" path is
unveiled (libunicodedata.so.serenity) as the symlink (libunicodedata.so)
itself cannot be unveiled.
Remove note about CMake Tools as version 1.9.0 has shipped and no longer
needed. Update details for files to latest versions and allow easier
copy and paste into an empty file.
This is a deprecated feature that is still in use in some older games,
most notably Grim Fandango in ScummVM makes heavy use of it.
Luckily, since you can only draw convex polygons, the end result is
exactly the same as when you would have used `glBegin(GL_TRIANGLE_FAN)`
- so we just reuse that code as-is.
Implement support for the `GL_TEXTURE` matrix mode, the texture matrix
stack and texture coordinate matrix transformation.
Also, an unused `m_current_matrix` was removed to make room for
`m_texture_matrix`.
In OpenGL, texture coordinates can have up to 4 values. This change
will help with easy application of texture coordinate matrix
transformations in the future.
Additionally, correct the initial value for texture coordinates to
`{ 0.f, 0.f, 0.f, 1.f}`.
Not much to say here, this is an implementation of this call that
accesses the actual limit constant that's used by the VirtualFileSystem
class.
As a side note, this is required for my eventual Qt port.
As pointed out by BertalanD on Discord, POSIX specifies that
_SC_SYMLOOP_MAX (implemented in the following commit) always needs to be
equal or more than _POSIX_SYMLOOP_MAX (8, defined in
LibC/bits/posix1_lim.h), hence I've increased it to that value to
comply with the standard.
The move to header is required for the following commit - to make this
constant accessible outside of the VFS class, namely in sysconf.
The actual value is unchanged, but the previous `0xffffffff` was an
unsigned value, which lead to clang getting mad at `foowc() == WEOF`.
This commit makes it a signed int on clang, which *should* serve
the same purpose and not lead to clang getting mad at us.
