There was no need to use FlyString for error messages, and it just
caused a bunch of churn since these strings typically only existed
during the lifetime of the error.
This was resulting in a whole lot of rebuilding whenever a new IDL
interface was added.
Instead, just directly include the prototype in every C++ file which
needs it. While we only really need a forward declaration in each cpp
file; including the full prototype header (which itself only includes
LibJS/Object.h, which is already transitively brought in by
PlatformObject) - it seems like a small price to pay compared to what
feels like a full rebuild of LibWeb whenever a new IDL file is added.
Given all of these includes are only needed for the ::initialize
method, there is probably a smart way of avoiding this problem
altogether. I've considered both using some macro trickery or generating
these functions somehow instead.
This commit introduces a WEB_SET_PROTOTYPE_FOR_INTERFACE macro that
caches the interface name in a local static FlyString. This means that
we only pay for FlyString-from-literal lookup once per browser lifetime
instead of every time the interface is instantiated.
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>
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.
