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

20 commits

Author SHA1 Message Date
Bernd Busse
f6780cb394
tests: add test case for #465 2020-08-31 20:22:15 +02:00
Yuxuan Shui
b1b40ed058
tests: add a test case for #299
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-04-11 01:52:42 +01:00
Yuxuan Shui
3b38b56d89
tests: common: add set_window_state
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-04-10 16:57:21 +01:00
Yuxuan Shui
f504b1d37e
tests: common: factor out intern atom calls
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-04-10 16:57:20 +01:00
Yuxuan Shui
1614ae60a7
tests: common: don't fail when atom doesn't exist yet
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-04-10 16:57:19 +01:00
Yuxuan Shui
25832fcc36
tests: common: add find_32bit_visual
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-04-10 16:57:18 +01:00
Yuxuan Shui
fd5c95d92a
tests: common: add set_window_class
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-04-10 16:57:17 +01:00
Yuxuan Shui
0116912095
tests: common: set both WM_NAME and _NET_WM_NAME
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-04-10 16:57:06 +01:00
Bernd Busse
c1d985eb7c
tests: update testcase for #314
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.
2020-04-08 23:22:11 +01:00
Yuxuan Shui
397710ac27
tests: add testcase for #314
This should be fixed by merging #364.

Thanks @tryone144 for pointing out the root cause.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-04-05 02:52:12 +01:00
Yuxuan Shui
05e8d0f305
testcases: update comments in issue357.py
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-04-04 17:50:06 +01:00
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