Namely, for CalGrayColorSpace, CalRGBColorSpace, LabColorSpace.
Fixes a crash rendering any page of Adobe's 5014.CIDFont_Spec.pdf
(which uses CalRGBColorSpace with an indirect dict: The dict is
object `92 0`, and many color spaces are inline objects referring
to it).
Since we already call `Painter::flush()` in `PageHost::paint()` we do
not need to do that again in `PaintingCommandExecutorGPU` destructor.
This makes GPU painting run noticeably faster because `flush()` does
expensive `glReadPixels()` call.
Array.length is magical (since it has to reflect the number of elements
in the object's property storage).
We now handle it specially in jitted code, giving us a massive speed-up
on Kraken/ai-astar.js (and probably many other things as well) :^)
Until now, the unwind context stack has not been maintained by jitted
code, which meant we were unable to support the `with` statement.
This is a first step towards supporting that by making jitted code
call out to C++ to update the unwind context stack when entering/leaving
unwind contexts.
We also introduce a new "Catch" bytecode instruction that moves the
current exception into the accumulator. It's always emitted at the start
of a "catch" block.
The differencing predictor is a different way to encode pixels in TIFF
images. Every pixel is encoded as a difference with the previous column
of the image, except the first column, obviously.
This parameter is materialized by a new tag for which reading was also
implemented.
Some users of the LZW algorithm use a different value to determine when
the size of the code changes. GIF increments the size when the number of
elements in the table is equal to 2^code_size while TIFF does it for a
count of 2^code_size - 1.
This patch adds the parameter m_offset_for_size_change with a default
value of 0 and our decoder will increment the code size when we reach
a table length of 2^code_size + m_offset_for_size_change. This allows us
to support both situations.
Previously, it was possible for a `TextDescriptionTagData` object with
an incorrect Macintosh ScriptCode description length to cause a buffer
overflow.
Audio loaders currently always output two channels, even if they were
encoded as mono. Therefore, we have to hardcode the channel count in
our audio plugin to avoid crashing until we can handle mono or multi-
channel audio better.
Fixes#21898
I didn't find example code for this and the AI assistant did very
poorly on this as well. So I had to write it all by myself!
It can be much more efficient I think, but I think the overall
shape is maybe roughly fine.
This only tracks whether the relevant steps should be executed at some
future (but very soon) time. This time will eventually be whenever the
"update animations and send events" procedure is invoked.
Framebuffer object is allocated using OpenGL's API and is not platform
specific which means it could be used on both macOS and Linux unlike
EGL specific PBuffer.
Before, we were using a feature of OpenGL that allows specifying a
pointer to allocated vertex data without creating VBO and VAO, but as
I found out, it does not work on macOS.
This implementation is basically a copy-paste of the SECP256r1
implementation with all "256" replaced with "384".
In the future it might be nice to make this generic, instead of having
two almost identical copies of code.
