Previously we were inconsistent by generating code for enum definitions
but not generating code for dictionaries. With future changes to the
IDL generator to expose helpers to convert to and from IDL values
this produced circular depdendencies. To solve this problem, also
generate the dictionary definitions in bindings headers.
Generate exact JS buffer types for exact IDL buffer arguments instead
of widening them to BufferSource or ArrayBufferView.
This fixes cases like TextEncoder.encodeInto(), whose IDL requires
a Uint8Array destination. Previously the generated binding accepted
any BufferSource, so DataView, other typed arrays, and
ArrayBuffer-backed values were let through. With exact conversion,
those are rejected at the binding layer as expected.
Previously, the LibWeb bindings generator would output multiple per
interface files like Prototype/Constructor/Namespace/GlobalMixin
depending on the contents of that IDL file.
This complicates the build system as it means that it does not know
what files will be generated without knowledge of the contents of that
IDL file.
Instead, for each IDL file only generate a single Bindings/<IDLFile>.h
and Bindings/<IDLFile>.cpp.
Before this change, we were going through the chain of base classes for
each IDL interface object and having them set the prototype to their
prototype.
Instead of doing that, reorder things so that we set the right prototype
immediately in Foo::initialize(), and then don't bother in all the base
class overrides.
This knocks off a ~1% profile item on Speedometer 3.
https://webaudio.github.io/web-audio-api/#AnalyserNode
Most of the interface is naively implemented. Container types
probably need adjusted (Vector<double> is used for all the processing).
A Fourier Transform is needed, but that's waiting on either a 3rd
party library or a complex number type.
There are lots of simple miscellaneous filters that need to be applied.
It could be reasonable to implement from scratch, supposing that
it can be parallelized. It might be hard to find one library with
everything. Not my call though.
Some additional scaffolding around blocks and render quanta is
probably needed before this is developed much further, which
probably comes in at the level of the AudioNode.
Co-authored-by: Tim Ledbetter <tim.ledbetter@ladybird.org>
