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

11 commits

Author SHA1 Message Date
Yuxuan Shui
e53ac7a6f9
event, win: delayed handling of shape notify
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-10-23 04:37:38 +01:00
Yuxuan Shui
f476a78ad1
event: don't eagerly add damage for configure notify
If a window receives multiple configure notifies in between 2 frames, we
add all the in between positions into damage, when we really just need
the starting and the end position.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-10-23 04:27:35 +01:00
Yuxuan Shui
a099678664
win: delayed handling of configure notify
Part of the configure notify handling which requires querying the X
server, has been moved into the X critical section.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-10-23 01:36:04 +01:00
Yuxuan Shui
f3ff7eff8c
event: delayed handling of window property changes
Move handling window property changes into the X critical section.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-10-23 00:15:54 +01:00
Yuxuan Shui
440157f20b
win, event: delayed handling of reparent notify
Instead of handling reparent notify on the spot by updating the client
windows, setup a flag on the window and call win_recheck_client later.

This makes handling of complex scenarios easier. As example, see the
case in issue #299.

Note this is not a complete fix for #299
2020-04-11 01:52:47 +01:00
Bernd Busse
ad8632b017
New backends: smoothly fade blur-texture on fade-in/-out
* Add new field `opacity_target_old` to `struct managed_win` for
tracking relevant `opacity_target` changes.
* Smoothly fade blur-texture opacity on window opacity changes (based on
window opacity), when the window was or will be fully transparent
(`w->opacity ~< 0.004`).
* Fixed alpha-clipping of the blur-texture when using `inactive-opacity` or
repeatedly setting window opacity with large fade intervals (should fix #314).
2020-04-08 23:22:06 +01:00
Yuxuan Shui
32754b0262
win: merge win::pending_updates and win::flags
These two flags are intended for subtly different things. I can probably
justify the distinction, but it's definitely difficult to explain. And
there is no obvious benefits to keep them separate.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-04-06 20:52:32 +01:00
Jerónimo Navarro
94c8927d7b win_defs.h: fix #240 2019-09-25 09:47:36 -03:00
Yuxuan Shui
9f3d3f2fba
win: add functions for delayed window updates
And a window update flag for mapping the window.

Also make sure related functions consider the case where the given window
has pending updates.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-09-20 02:22:46 +01:00
Yuxuan Shui
eecee130b8
win: split WIN_FLAGS_IMAGE_STALE
Split it into PIXMAP_STALE and SHADOW_STALE, this allows us to update
pixmaps and shadow images separately.

Also added PIXMAP_NONE and SHADOW_NONE, as redundancy to detect logic
errors.

Convenient constants and functions are provided for updating pixmap and
shadow together.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-09-20 01:25:07 +01:00
Yuxuan Shui
0ba7761bd5
Untangle headers
Thanks, clang -fmodules.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-08-10 00:56:26 +01:00