Prep for rasterizing each Navigable independently, where children must
paint before their parents — the event loop needs to walk documents in
an order where every child comes after its container. The HTML spec
already mandates such an order for the "docs" list: each document
appears after its container, with siblings in shadow-including tree
order.
Maintain m_documents in that sorted order, re-sorting lazily when a
document is registered or its navigable is reassigned.
The microtask queue is a pure FIFO (enqueue at back, dequeue from
front) but was using a Vector, making every dequeue O(n) due to
element shifting.
Replace it with AK::Queue which has O(1) dequeue. This makes a huge
difference when processing large numbers of microtasks, e.g. during
async-heavy JavaScript workloads where each `await` generates a
microtask.
Also add a for_each() method to AK::Queue so the GC can visit the
queued tasks.
Our existing coalescing mechanism for input events didn't prevent
multiple mousemove/mousewheel events from being processed between paint
cycles. Since handling these events can trigger style & layout updates
solely for hit-testing purposes, we might end up doing work that won't
be observable by a user and could be avoided by shceduling input events
processing to happen right before painting the next frame.
Instead of collecting all documents in a big vector and then filtering
the vector (twice!) with remove_all_matching(), we now pass a filter
callback to documents_in_this_event_loop_matching() and avoid all the
extra shuffling work.
Saw this stuff hogging ~20% of CPU time when profiling a WebContent
process in the middle of a WPT run.
Resulting in a massive rename across almost everywhere! Alongside the
namespace change, we now have the following names:
* JS::NonnullGCPtr -> GC::Ref
* JS::GCPtr -> GC::Ptr
* JS::HeapFunction -> GC::Function
* JS::CellImpl -> GC::Cell
* JS::Handle -> GC::Root
