While working on this PR, I introduced a bug where shadow images for
unmapped windows aren't properly recreated after unredirect/redirect.
The shadow image is freed during unredirect, OTOH redirect only set
IMAGE_STALE flags for mapped window, thus the shadow images for unmapped
windows will be missing.
This bug is already fixed in the previous commit. But the testcase is
good to keep nonetheless.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
So we can bundle this request together with other requests, making
reproducing time critical bugs easier.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
This is to allow us sending the root configure request together with
other requests. Making it easier to reproduce timing critical bugs.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Handle more (hopefully all) edge-cases when updating `opacity_target_old`:
* `MAPPING` transitions to `FADING` if new target is reached. Otherwise
no update.
* `FADING` clamps to current `opacity` if old target is too small.
* `UNMAPPING`/`DESTROYING` clamps to current `opacity` if old target is
too small.
Previously, root ConfigureNotify is handled immediately, by resetting
the backend, which in turn releases all the window images. This puts all
the windows into a state where they don't have images attached, which
they really should be in when the screen is redirected.
(To expand a little, a window without images should only exist if:
* It's an unmanaged window.
* Screen is unredirected.)
Normally, this kind of window could be fine, as the next render phase
will re-acquire images for them. However, if a window in this state is
destroyed with fading enabled, then the render phase won't try to
acquire images for it, causing it to go into the main rendering function
without images attached, and trigger an assertion.
This commit delays the handling of root ConfigureNotify until the render
phase. This way, the images will be immediately re-acquired after they
are released, thus prevent this problem from happening.
Also adds a testcase for this.
Fixes#357
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Previously win_set_shadow tries to release the shadow image when turning
off shadow for a window. When shadow is turned off _immediately_ after
it's turned on, picom won't have a chance to handle the delayed creation
of the shadow before win_set_shadow tries to release the shadow image,
causing a assertion failure because win_set_shadow tried to release a
non-existing image.
This commit makes releasing the shadow image delayed as well.
In theory, we could check the STALE flag in win_set_shadow before
release the image, but that duplicates the logic that is already in
win_process_flags.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
The compositor crashes when a window does:
has shadow -> no shadow -> has shadow
This is because when the shadow is turned off, the shadow image is not
freed, and this is catched by a later assertion.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
If a window is unmapped during the draw_callback re-run when the screen
is just redirected, that window won't get a chance to acquire a pixmap.
If fading is enabled, the compositor will try to render that window and
crash.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Yuxuan Shui