1
0
Fork 0
mirror of https://github.com/yshui/picom.git synced 2024-11-11 13:51:02 -05:00
Commit graph

9 commits

Author SHA1 Message Date
Yuxuan Shui
9332cba8df core: delayed handling of root ConfigureNotify
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>
2020-03-31 05:20:56 +01:00
Yuxuan Shui
b109526e15
tests: reduce some code duplication
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-03-30 11:49:38 +01:00
Yuxuan Shui
323a59b933
tests: add common functions useful for testing
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-03-30 11:16:56 +01:00
Yuxuan Shui
d4e76b271a
win: delayed release of shadow image
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>
2019-11-18 22:34:05 +00:00
Yuxuan Shui
db2c9ff0be
tests: add testcase for another case of #239
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>
2019-11-18 20:53:49 +00:00
Yuxuan Shui
9fc388e5bc
tests/issue239_2: add comments
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-09-28 23:29:19 +01:00
Yuxuan Shui
df67fb2508
tests: add testcase for #239, bug number 2
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>
2019-09-28 23:23:24 +01:00
Yuxuan Shui
44fd3f93f7
tests: add test case for #239
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-09-23 21:36:09 +01:00
Yuxuan Shui
bfb6cad648
tests: put test cases into their own folder
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-09-23 21:22:17 +01:00