PolytreeDE
/
picom
mirror of https://github.com/yshui/picom.git
1
0
Fork 0
Code Releases Activity
picom/tests/run_tests.sh

15 lines
677 B
Bash
Raw Normal View History

Run test cases in CI Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-08-04 18:57:30 +00:00
#!/bin/sh
tests: add test case for #239 Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-09-23 20:14:02 +00:00
set -e
rename: replace "compton" in the codebase leftovers: 1) config file path. Has to implement compatibility functionalities before we can change it. 2) links in man pages. Has to migrate the repo first. 3) _COMPTON_SHADOW, it has become a defacto standard, so we have to keep supporting it. 4) dbus names, undecided whether we should/could change it. Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-10-23 18:27:30 +00:00
exe=$(realpath $1)
Run test cases in CI Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-08-04 18:57:30 +00:00
cd $(dirname $0)
rename: replace "compton" in the codebase leftovers: 1) config file path. Has to implement compatibility functionalities before we can change it. 2) links in man pages. Has to migrate the repo first. 3) _COMPTON_SHADOW, it has become a defacto standard, so we have to keep supporting it. 4) dbus names, undecided whether we should/could change it. Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-10-23 18:27:30 +00:00
./run_one_test.sh $exe configs/empty.conf testcases/basic.py
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 04:01:14 +00:00
./run_one_test.sh $exe configs/issue357.conf testcases/issue357.py
rename: replace "compton" in the codebase leftovers: 1) config file path. Has to implement compatibility functionalities before we can change it. 2) links in man pages. Has to migrate the repo first. 3) _COMPTON_SHADOW, it has become a defacto standard, so we have to keep supporting it. 4) dbus names, undecided whether we should/could change it. Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-10-23 18:27:30 +00:00
./run_one_test.sh $exe configs/issue239.conf testcases/issue239.py
./run_one_test.sh $exe configs/issue239_2.conf testcases/issue239_2.py
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
./run_one_test.sh $exe configs/issue239_3.conf testcases/issue239_3.py
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
./run_one_test.sh $exe configs/issue239_3.conf testcases/issue239_3_norefresh.py
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 01:52:12 +00:00
./run_one_test.sh $exe configs/issue314.conf testcases/issue314.py
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-07 11:35:06 +00:00
./run_one_test.sh $exe configs/issue314.conf testcases/issue314_2.py
./run_one_test.sh $exe configs/issue314.conf testcases/issue314_3.py