This commit adds draw_ellipse() and moves the shared code
for circles and ellipses to draw_ellipse_part().
draw_ellipse_part() can draw an entire circle in one call using
8-way symmetry and an ellipse in two calls using 4-way symmetry.
This method will center a group of window rects, within some
bounds, accounting for the properties of the currently selected theme
(i.e. border width, title height, etc).
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>
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 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.
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.
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.
Since the layout_box of a SVGGraphicsPaintable is already casted to the
right type, the underlying dom_node was also always of the right type.
This triggers a warning on Lagom builds.
This was changed a while ago so the generated files are placed in the
Build directory. Let's remove the gitignore file so any old version of
the files stop conflicting with the new generated versions.
The change in 3ec0183 wasn't actually correct, the spec tells us to set
the "prototype" property of the function (created with a prototype of
%GeneratorFunction.prototype% itself) to a newly created object:
OrdinaryObjectCreate(%GeneratorFunction.prototype.prototype%)
Clang didn't accept the friend declaration here, as the class has a
requires clause attached to it, and I couldn't immediately figure
out what it wants instead.
Add accessors for VectorN::m_data and use those where needed instead
for now.
The DisplayConnector class is meant to replace the FramebufferDevice
class. The advantage of this class over the FramebufferDevice class is:
1. It removes the mmap interface entirely. This interface is unsafe, as
multiple processes could try to use it, and when switching to and from
text console mode, there's no "good" way to revoke a memory mapping from
this interface, let alone when there are multiple processes that call
this interface. Therefore, in the DisplayConnector class there's no
implementation for this method at all.
2. The class uses a new real-world structure called ModeSetting, which
takes into account the fact that real hardware requires more than width,
height and pitch settings to mode-set the display resolution.
3. The class assumes all instances should supply some sort of EDID,
so it facilitates such mechanism to do so. Even if a given driver does
not know what is the actual EDID, it will ask to create default-generic
EDID blob.
3. This class shifts the responsibilies of switching between console
mode and graphical mode from a GraphicsAdapter to the DisplayConnector
class, so when doing the switch, the GraphicsManagement code actually
asks each DisplayConnector object to do the switch and doesn't rely on
the GraphicsAdapter objects at all.
Our move to floating point precision has eradicated the pixel artifacts
in Quake 1, but introduced new and not so subtle rendering glitches in
games like Tux Racer. This commit changes three things to get the best
of both worlds:
1. Subpixel logic based on `i32` types was reintroduced, the number of
bits is set to 6. This reintroduces the artifacts in Quake 1 but
fixes rendering of Tux Racer.
2. Before triangle culling, subpixel coordinates are calculated and
stored in `Triangle`. These coordinates are rounded, which fixes the
Quake 1 artifacts. Tux Racer is unaffected.
3. The triangle area (actually parallelogram area) is also stored in
`Triangle` so we don't need to recalculate it later on. In our
previous subpixel code, there was a subtle disconnect between the
two calculations (one with and one without subpixel precision) which
resulted in triangles incorrectly being culled. This fixes some
remaining Quake 1 artifacts.
