fix the same issue in the legacy backends, see the previous commit for
details. this commit also removes the x_validate_pixmap function because
it was used only in the get_root_tile function and the fix pretty much
implies and embeds it.
if the root background pixmap's depth doesn't match the root window's
depth, find a suitable visual for the root background pixmap's depth and
use it instead of the root window's visual
On a second thought, the `corner-radius-rules` is a user noticeable
behavioral change, it should be more prominent.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
This is a follow up to 81d137a3cc and
bug #704. Basically a window will have a `XCB_NONE` as `client_win` if its
previous client_win detached and then the window itself is immediately
destroyed. Because the window is destroyed we couldn't call
`win_recheck_client` so its `client_win` will remain `XCB_NONE`.
However, it turns out we have a convention of setting `client_win` to
the window itself if windows that don't have a client window. So make
sure this convention is followed even for destroyed windows.
Doesn't really fix anything, just to make sure an invariant holds.
Related: #704
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
The intention is we update this file as PRs are merged, so the workload
when making a new release is reduced.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Present extension based scheduler doesn't work well on NVIDIA drivers.
GLX_SGI_video_sync is less accurate, but is rumoured to work. See
[kwin's usage](https://invent.kde.org/plasma/kwin/-/blob/master/src/
backends/x11/standalone/x11_standalone_sgivideosyncvsyncmonitor.cpp)
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
It's kind of dumb anyway. If we get damage event right after a vblank
event, we would waste the whole vblank.
Instead improve the frame scheduling logic to target the right vblank
interval. This only affects smart_frame_pacing anyway.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Right now we rely on `reschedule_render_at_vblank` being scheduled for
the render finish check. Which means we will only know if a frame has
finished rendering the next time we queue a render. And we only check at
vblank boundary, which means when a render is queued we have to wait for
the next vblank, when had we checked earlier, we will be able to start
rendering immediately
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
