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>
I noticed sometimes full frame rate video is rendered at half frame rate
sometimes. That is because the damage notify is sent very close to
vblank, and since we request vblank events when we get the damage, we
miss the vblank event immediately after, despite the damage happening
before the vblank.
request next ...... next next
damage vblank vblank vblank
| | | ...... |
v v v v
---------------------->>>>>>---------
`request vblank` is triggered by `damage`, but because it's too close to
`next vblank`, that vblank is missed despite we requested before it
happening, and we only get `next next vblank`. The result is we will
drop every other frame.
The solution in this commit is that we will keep requesting vblank
events, right after we received a vblank event, even when nobody is
asking for them. We would do that for a set number of vblanks before
stopping (currently 4).
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
