This also makes us a bit more accurate, due to better rounding of
intermediate results.
This also gives us the flush-to-zero and denormals-are-zero SSE settings
for free! (Assuming UE is build with SSE)
This is only enabled for clang right now, because it does not seem to
work on GCC.
Also fixes the types of two intermediate results
Co-authored-by: kleines Filmröllchen <filmroellchen@serenityos.org>
This allows direct inlining and hides away some assembly and
bit-fiddling when manipulating the floating point environment.
This only implements the x87/SSE versions, as of now.
We were always calling llround[fd], even for floating point targets.
Also for rounding to integer, we don't need to have C99's rounding rules
and can just cast, assuming the standard rounding mode.
This uses the `fistp` and `cvts[sd]2si` respectively, to potentially
round floating point values with just one instruction.
This falls back to `llrint[fl]?` on aarch64 for now.
This way, we can change the constant in one place. Note that this
requires the use of nested format strings, which is slightly ugly but
safe to do in this instance.
This constant is currently 3 but can be changed easily or integrated
into a user setting. Note that the results are not ideal because during
pretty-printing we're not using any nice rounding rules, so many
percentage values will actually appear as 0.399999 even though they were
rounded to three digits.
This has been overkill from the start, and it has been bugging me for a
long time. With this change, we're probably a bit slower on most
platforms but save huge amounts of space with all in-memory sample
datastructures.
- HighlightWindow text and strip colors now dark blue.
- MovingWindowShadow color made lighter, so that it's more visible.
- RubberBand now has silver colors.
Also removes mrsh from the list of ports missing descriptions. I tried
to be descriptive about the patches, but as I picked this port up from
someone else, I'm not 100% sure how to best explain the patches.
Using a Vector<Value> is unsafe as GC cannot see the stored values.
This is then vended to outside users of ConsoleClient, e.g. LibWeb and
WebContent, which is then outside of LibJS's control.
An example issue is if the client stores it for later use and forgets
to visit the stored values, meaning they can be destroyed at any time.
We can save the client from this by vending a MarkedVector<Value> to
them.
Physical hardware doesn't care about scale factors as this is a concept
being related to WindowServer and userland applications. To ensure we
provide the correct display resolution details to HardwareScreenBackend
objects, we must keep a separate Gfx::IntRect object that reserve the
correct details.
There was an awful lot of JS::Value <-> double conversion going on, even
through these AOs only work with number values anyway.
They don't need a global object either as they won't allocate or throw,
that was simply to pass it to infallible calls of ToIntegerOrInfinity.
In many cases we already know a certain value is a number, or don't have
JS values at all and would need to wrap doubles in a value. To optimize
these cases and avoid having to pass a global object into functions that
won't ever allocate or throw, add a standalone implementation of this
function that takes and returns doubles directly.
This fixes a weird bug that when sometimes a user tried to switch to
console mode, the screen was frozen on graphics mode. After a hour of
debugging this, it became apparent that the problem was that we left the
y offset of the bochs graphics device in an invalid state, so it was not
zero because the WindowServer changed it, and the framebuffer console
code is not aware of horizontal and vertical offsets of the framebuffer
screen, leading to the problem that the framebuffer console updates the
first framebuffer (y offset = 0), but hardware was indicated to show the
second framebuffer (y offset = first framebuffer height).
Therefore, when doing a switch between these modes, always set the y
offset to be zero.
This hack is not necessary anymore, because WindowServer will try
constantly to write the framebuffer contents to the display connector
devices. After a switch from console mode to graphical mode, the write
syscall on these devices will not be silently ignored but will actually
write to the framebuffer screen.
This let us test the VMWare SVGA adapter easily. We already use the std
vga (which is compatible with bochs-display that only lacks VGA support)
on the i440FX QEMU machine so we keep testing it there too, and on the
Q35 machine we use a bochs-display device as secondary display.
