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 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.
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.
As the framebuffer devices are gone by now, searching for them makes no
sense, so instead, let's remove this check now. If the user requested to
boot into text mode, he probably knows what he is doing and we should
not try to warn him about this.
This implements the "close modified" icon on the terminal,
as well as several close warnings:
- A warning there is a foreground process running
- If there is a background process running
- Or if there are multiple background processes running
Fixes#13751
Instead of just printing 'ECMAScriptFunctionObject' (and leaking an
implementation detail in the process - this is not a public facing name)
let's instead print a different type string for each function kind, and
only keep the old class_name() printing for other JS::FunctionObject
subclasses.
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%)
This patch removes the separate CookiesTab.gml file used to define the
layout of the cookies and local storage tabs and moves those defintions
into the StorageWidget.gml file.
Unconditionally adding the item height offset to the adjusted vertical
position of a menu leads to an incorrect position if we previously
clamped the translation offset so the menu doesn't go off-screen.
Also add some comments to this coordinate math. Always add comments to
coordinate math.
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.
ValueFormat::text_formatter is called with a u64 retrieved from
GraphWidget::m_values. However, the function pointer definition used
size_t and all the users of text_formatter used int. If bytes was over
~2 billion, we would interpret bytes to be negative. We then pass this
into `human_readable_size` which converts it to a u64, making it out to
be about 15.9 EiB.
This is fixed by making everything in the path take a u64.
This ioctl is more appropriate when the hardware supports flushing of
the entire framebuffer, so we use that instead of the previous default
FB_IOCTL_FLUSH_HEAD_BUFFERS ioctl.
Such mechanism will be used by the Intel Graphics driver, because we
lack support of changing the resolution on this driver currently, so,
when WindowServer will try to mode-set the display then it will fail,
and will use the safe mode-setting call instead to be able to show
something on screen.
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.
