| Age | Commit message (Collapse) | Author |
|---|
|
Long live the DisplayConnector object!
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
We shouldn't expose the VirtIO GPU3DDevice constructor as public method,
so instead, let's use the usual pattern of a static construction method
that uses the constructor within the method.
|
|
|
|
|
|
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.
|
|
|
|
This method will be used to ease usage with the structure when we need
to do virtual pointer arithmetics.
|
|
This will be used later in the kernel code to simplify the EDID handling
code.
|
|
These definitions will be used later when applying the DisplayConnector
design on the Bochs driver.
|
|
|
|
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.
|
|
|
|
This value was always overwritten. No functional changes.
|
|
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.
|
|
|
|
The type `Vector<N, int>` is used often enough that it warrants its own
dedicated type.
|
|
|
|
The dot product is effectively the same as `interpolate()`, allowing us
to use `VectorN`. No functional changes.
|
|
No functional changes.
|
|
This increases memory usage for textures 4-fold, but allows us to
completely remove calls to `(un)pack_color` in a very hot loop.
|
|
No functional changes.
|
|
This allows for faster rebuilds when the implementation changes.
|
|
We were splitting these API wrappers up into different files without a
quantifiable benefit. Now, it's extremely clear where the direct API
implementation lives. :^)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is an editorial change in the ECMA-262 spec.
See: https://github.com/tc39/ecma262/commit/656f0cf
|
|
|
|
Previously it was only transforming ASCII characters.
|
|
|
|
|
|
|
|
A trick I learned from @linusg which is very useful and needs
to be a part of PRs where images are involved.
|
|
The file is now renamed to Queue.h, and the Resampler APIs with
LegacyBuffer are also removed. These changes look large because nobody
actually needs Buffer.h (or Queue.h). It was mostly transitive
dependencies on the massive list of includes in that header, which are
now almost all gone. Instead, we include common things like Sample.h
directly, which should give faster compile times as very few files
actually need Queue.h.
|
|
This completely removes WavLoader's dependency on LegacyBuffer: We
directly create the result sample container and write into it. I took
this opportunity to rewrite most of the sample reading functions as a
single templated function, which combined with the better error handling
makes this "ported" code super concise.
|
|
This makes the code much more readable and concise, reduces the size of
the WavLoader class itself, moves almost all fallible initialization out
of the constructor and should provide better error handling in general.
Also, a lot of now-unnecessary imports are removed.
|
|
* All clang-tidy warnings fixed except read_header cognitive complexity
* Use size_t in more places
* Replace #define's with constexpr constants
* Some variable renaming for readability
|
|
This was long overdue; as of writing this I saw another question about
something that seems obvious to me who spent a bunch of time with the
system.
|
|
Not sure what happened here, but the comment does not match the spec,
and so the FIXME I added is not actually an issue.
|
|
This is an editorial change in the ECMA-262 spec.
See: https://github.com/tc39/ecma262/commit/33ea99e
|
