Contrary to IEEE formats, x86's 80-bit extended floats need the topmost
mantissa bit to be 1 or else a special kind of NaN is produced. We fix
this by reinserting the special bit if necessary.
Whenever the floating-point values are in integer range, we can use the
various FCVT functions with static rounding mode to perform fast
rounding. I took this opportunity to clean up the architecture
differentiation for these functions, which allows us to use the software
rounding implementation for all extreme and unimplemented cases,
including AArch64.
Also adds more round & trunc tests.
This allows us to easily use an appropriate integer type when performing
float bitfield operations.
This change also adds a comment about the technically-incorrect 80-bit
extended float mantissa field.
gcc can't seem to figure out that the address of a member variable of
AK::Atomic<u32> in AtomicRefCounted cannot be null when fetch_sub-ing.
Add a bogus condition to convince the compiler that it can't be null.
Most of these now just await the image decoding, equivalent (ish) to
the old behavior. A more async-aware refactor should happen some time
in the future.
The HTMLLinkElement caller is a bit hairy, so we shove an await() in
there temporarily. This is sure to cause fun times for anyone debugging
task/microtask execution order.
ImageDecoder now queues up image decoding requests and returns the
images back to the caller later. ImageDecoderClient has a new
promise-based API that allows callers to attach their own resolve/reject
handlers to the responses from ImageDecoder.
Weak symbols can be left unresolved, and code is supposed to check if
they're null at runtime before using them. Handle them appropriately
instead of refusing to load.
Previously the 'device independent pixels' (which consider scaling)
were used, and then scaling would be applied again when calculating the
screen width for CSS.
There's no need to capture things as Handle when using HeapFunction.
In this case, it was even creating a strong reference cycle, which ended
up leaking.
It previously resided in LibWebView to hide the details of launching a
singleton process. That functionality now lives in LibCore. By moving
this to Ladybird, we will be able to register the process with the task
manager.
This just moves the code to launch a single process such as SQLServer to
LibCore. This will allow re-using this feature for other processes, and
will allow moving the launching of SQLServer to Ladybird.
This will be needed to collect statistics from processes that do not
have anything to do with LibWebView. The ProcessInfo structure must be
virtual to allow callers to add application-specific information.
Sometimes I like to play around with running Ladybird tests using full
blown Ladybird instead of just headless browser to interactively mess
around with the test page. One problem with this is that the internals
object is not exposed in this mode.
This commit supports this usecase by adding an option to specifically
expose the internals object without needing to run headless-browser
in test mode.