These wrappers will make it much easier to do various operations on the
different ArrayBuffer-related classes in LibWeb compared to the current
solution, which is to just accept a Handle<Object> everywhere (and use
"any" in the *.idl files).
Co-Authored-By: Matthew Olsson <mattco@serenityos.org>
With this change, we now have ~1200 CellAllocators across both LibJS and
LibWeb in a normal WebContent instance.
This gives us a minimum heap size of 4.7 MiB in the scenario where we
only have one cell allocated per type. Of course, in practice there will
be many more of each type, so the effective overhead is quite a bit
smaller than that in practice.
I left a few types unconverted to this mechanism because I got tired of
doing this. :^)
DOMMatrix fromMatrix was using create_from_dom_matrix_2d_init to make
a DOMMatrix for it's init struct this is wrong because only the 2D
params of the DOMMatrix are put into the new matrix. I have added
a non 2D version of that function that takes the full DOMMatrixInit
so now fromMatrix works correctly again. I also have added some
text tests to test if it works correctly.
I split the dommatrix.html text tests into multiple files because that
file was becoming to big so now every sub function is a seperate file.
The matrix used in the spec is column-major but Gfx::Matrix4x4 is
row-major so we need to transpose the values. This will fix internal
operations on that matrix. Because we also transposed the readonly
matrix property getters the matrix is again transposed when reading
so the JavaScript world only sees a column-major matrix.
Stop worrying about tiny OOMs. Work towards #20449.
While going through these, I also changed the function signature in many
places where returning ThrowCompletionOr<T> is no longer necessary.
