We now enumerate all IVSHMEM devices, sort them based on PCI bus, slot,
and function numbers, then index from the resulting order. This should
be consistent across boots.
To help the user identify the correct IVSHMEM device, we also print the
list of IVSHMEM devices on startup.
We implement nanotime by converting QueryPerformanceTimer output with
floating point arithmetic. This is necessary to preserve precision on
platforms where each tick is not an integer number of nanoseconds.
Furthermore, struct timespec is included C11 and appears to be supported
on Windows, so we no longer need to #ifdef it out.
Now that we are drawing with damage rects, when the window is hidden and
then exposed the window may not get fully redrawn. This provides
`app_invalidateWindow` for the display server backend to call when the
screen needs a full redraw.
When a new client connects to our session the host will repeat the last
valid frame for the new client. This change will detect this and skip
the duplicated frame.
1. Correctly detect ON state so that host is not built as -march=native by
default.
2. Merge OFF and GENERIC options as we need at least -march=nehalem to build
properly.
This is necessary in case overlays change size. When this happens, we must
damage the larger of the overlays' rectangles this frame and last frame.
This erases the overlay from where it is no longer appears.
In order to do this, we must keep track of the rectangles for every overlay
with no exception. We cannot short-circuit the generation of rectangles if
we run out of buffer space, and we must allocate space for MAX_OVERLAY_RECTS
rectangles for every frame. Otherwise, we will not know where to erase the
overlay if it disappears.
When our window is destroyed, our timers are also destroyed. This causes our
attempt at destruction to fail. Instead, set MessageHWND to NULL in the
WM_DESTROY handler and don't try destroying the timers if the window is gone.
This is desirable because certain uncommon configurations like libdecor or
clang may break, and this shouldn't stop us from seeing if unrelated changes
pass.
DestroyWindow can only be invoked on the thread that created the window.
All other threads must use WM_CLOSE or another message to signal tell the
window to destroy itself.
