Booting without a wallpaper is significantly faster in QEMU when the
host machine is under load (e.g while recording the screen..)
Using a wallpaper is now optional. :^)
An interactive application to modify the current display settings, such as
the current wallpaper as well as the screen resolution. Currently we're
adding the resolutions ourselves, because there's currently no way to
detect was resolutions the current display adapter supports (or at least
I can't see one... Maybe VBE does and I'm stupid). It even comes with
a very nice template'd `ItemList` that can support a vector of any type,
which makes life much simpler.
We shouldn't assume that the pitch of some arbitrary bitmap memory that
we're wrapping is going to be 16-byte aligned. Instead, just take the
pitch as a parameter.
Also update WindowServer to pass the pitch to the framebuffer bitmaps.
The main changes are twofold:
* Buffer flipping is now controlled by the m_screen_can_set_buffer flag
in WSCompositor. This flag, in turn, is impacted by m_can_set_buffer
flag, in WSScreen. m_can_set_buffer is set in the WSScreen constructor
by checking the return value of fb_set_buffer. If the framebuffer
supports this operation, it will succeed, and we record this fact. This
information is then used by WSCompositor to set its own
m_screen_can_set_buffer flag.
* WSScreen now only requests a resolution change of the framebuffer. The
driver itself is ultimately responsible for what resolution or mode is
actually set, so WSScreen has to read the response from that request,
and has no choice but to accept the answer. This allows the driver to
choose a "close enough" value to what was requested, or simply ignore
it.
The result of this is that there is no special configuration necessary
for WindowServer to work with reduced-capability framebuffer devices.
We can't rely on all hardware to give us a way to flip between the back
and front buffer.
This mode should actually perform slightly better but may show some tearing
as we don't have a way to know when we're in vertical retrace.
Instead of LibGUI and WindowServer building their own copies of the drawing
and graphics code, let's it in a separate LibDraw library.
This avoids building the code twice, and will encourage better separation
of concerns. :^)
Previously we were rendering the whole menubar on every compose(),
even if nothing changed about it. Now it's in its own window and can
be invalidated and painted separately.
d66fa60fcf introduced the use of a timer
to coalesce screen updates. This is OK, but it does introduce update
latency.
To help mitigate the impact of this, we now have a second (immediate)
timer. When a compose pass is first triggered, the immediate timer will
allow the compose to happen on the next spin of the event loop (so, only
coalescing updates across a single event loop pass). Any updates that
trigger while the delayed timer is running, though, will be delayed to
that (~60fps) timer.
This fixes#103.
