Commit Graph

179 Commits

Author SHA1 Message Date
b063e9a3be win: mark_client: print slightly more info in error logs
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-04-11 16:01:00 +01:00
4d55bc8dbe win: assert server is grabbed in win_recheck_client
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-04-11 02:40:50 +01:00
f8f1758137 win: demote log_error in win_clear_flags
Flags might be cleared on a destroyed window, if it's set because of an
event received before the window is destroyed.

Eventually we want to delay the handling of destroy notify as well.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-04-11 02:39:23 +01:00
660d16f555 win: update mode in win_on_factor_change
win_on_factor_change is called when client window changed for a frame,
in that case, the mode of the window could change.

Related: #299

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-04-11 01:52:47 +01:00
176718ad3b Revert "Revert previous fix for #299"
This reverts commit 04fe4a76b2.

This brings back the previous incomplete fix attempt for #299. See the
commit message of the revert for why it's incomplete.

A different fix is then attempted, see commit xxxxxxx for how that fix
works.

However, the second fix is incomplete by itself as well. The reason is
that i3 reparent the real window to the frame first, before destroying
the placeholder client of that frame. So briefly, that frame would have
2 client windows. And the frame is mapped before the placeholder is
destroyed. So even though we only call win_recheck_client when/if the
frame window is mapped, it can still be called when there are 2 client
windows, it would pick up the wrong client window in that case.

So what we need is to combine both fixes.

The second fix makes sure we are up to date on the client window
information when we starts to listen for events on the frame window;
while the first fix would keep us up to date afterwards.

This revert also includes a fix for assertion failure raised in #371

See #299 for root cause of the bug.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-04-11 01:52:47 +01:00
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
132332c483 win: remove unused parameter ignore_state
remove unrequired parameter `ignore_state` of
`win_calc_opacity_target()` that was always `false` now.
2020-04-08 23:22:11 +01:00
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
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
df0be9e990 Move find_client_win to win.c
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-04-06 20:24:16 +01:00
04fe4a76b2 Revert previous fix for #299
Commits reverted:
b652e8b58d
bdf809d039
e9ab970989
481ac54f67

While those commits themselves could be useful even if they don't
completely fix #299, they come with the risks of introduce more
unforeseen bugs, which outweigh their benefit, so revert them.

A brief explanation of their problem:

The fix hinges on the destroy event of the client window to work.
However, the client window could be destroyed so fast, before we even
handle the map, or even the create, event of the frame. And we won't be
listening for substructure events on the frame at the point the client
window is destroyed. Thus completely miss the client window destroy
event.

Because of the inherent racy nature of Xorg, this approach is really
difficult to make work.

Fixes #371

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-04-06 20:22:54 +01:00
e9ab970989 event: destroy: recheck client instead of unmark client
We detach the client window from its frame when it's destroyed, so later
a new window can be attached to that frame. But turns out that's not
enough.

When i3 restarts, it attaches a placeholder window to the frame, then
the real window, and only after that, it will destroy the placeholder.
The real window will fail to attach as the frame already has a client.
When the placeholder is destroyed, we have to call recheck client to
pick up the real window that failed to attach previously.

Related: #299

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-04-05 22:45:35 +01:00
68fa49cf59 win: rename find_toplevel_nocache to find_managed_window_or_parent
My previous understanding of this function is incorrect. Hopefully I got
it right this time.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-04-05 21:20:58 +01:00
53bb488530 win: rename find_toplevel2 to find_toplevel_nocache
So it is slightly clearer what is the difference to find_toplevel().

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-04-05 20:46:20 +01:00
8e440af222 win: print more debug messages on opacity change
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-04-05 02:50:14 +01:00
ee35bd873a win: always track property changes
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-03-29 19:15:07 +01:00
97db599fd8 win: always update frame extents
Frame extents are only updated when the window has frame_opacity < 1.
However, window frames can have inherent transparency, and not having
the frame extents information for those windows breaks blur-background-frame.

Fixes #345

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-03-22 16:55:45 +00:00
d332648d17 win: consolidate calls to win_update_focused
The focused state is a derivative state of the raw focused state (i.e.
whether the window is actually focused), with focus rules applied.

Here, we consolidate the calculation of the focused state into the
win_on_factor_change function, and replaced all calls to
win_update_focused with win_on_factor_change.

Also, the opacity update in win_update_focused is moved to
win_on_factor_change, as there could be opacity rules depending on the
focused state, so opacity must only be updated after
win_update_opacity_rule is called.

Related: #266 #317

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-03-17 19:54:20 +00:00
03895b711c win: simplify win_on_factor_change
Always refresh derivative window states in win_on_factor_change, without
checking if there are rules set.

c2_match is a no-op when there is no rules set. And we want to
consolidate derivative window state updates to one place,
win_on_factor_change is a good choice for that.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-03-17 19:36:28 +00:00
d2e323c985 win: clarify what win_is_focused_real means
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-03-17 19:19:13 +00:00
fb3305fb9b win: fix calculation of window frame region
The geometry returned by xcb_get_geometry doesn't include the window
border, so we have to include that when calculating the frame.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-03-17 18:32:34 +00:00
d9b407c6b4 win: fix assertion failures in old backends
These asserts only hold when using the experimental backends.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-03-17 17:31:19 +00:00
93f89b8603 win: fix transparency detection
Previously, when frame_opacity is < 1, we consider windows with frames to be
WIN_FRAME_TRANS immediately, without even checking if the body of the window
is transparent. The result is a transparent window is seen as a opaque window
with only a transparent frame, causing its background to not be blurred.

Fixes #211
2020-03-11 21:00:47 +00:00
51034249cc win: handle shadow image errors more gracefully
Currently if the shadow image fails to bind, the entire window is marked
as having image errors. So nothing of that window will render, even if
the window image itself is fine.

The commit cause shadow to be disabled when shadow image fails, instead
of marking the window.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-02-07 21:35:34 +00:00
b026708026 Partially handle _NET_WM_BYPASS_COMPOSITOR
Unredirect the screen when some window sets _NET_WM_BYPASS_COMPOSITOR
to 1, but ignore the case where some window requests the screen to be
redirected by setting _NET_WM_BYPASS_COMPOSITOR to 2.

Closes #267

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-01-18 18:02:41 +00:00
c9417bf367 x: trivial function renames
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2020-01-18 17:26:53 +00:00
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
896fe20098 win: release shadow image when shadow is turned off
fix a assertion error when the shadow is turned back on after being
turned off.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-11-18 21:00:40 +00:00
9a88d971d5 win: fix assertion failure in win_release_images
The assertion check for condition that are too board.

If we get multiple root config event in a row, then we might find
ourselves trying to release a image that was released in a previous
backend destruction and is yet to be bound (IOW, the window will have
IMAGES_NONE _and_ IMAGES_STALE set), causing the assertion to fail.

This commit relax the check, so we don't check if STALE is set when NONE
is set.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-11-13 21:59:26 +00:00
a0712274ff win: fix transparency detection for windows without a WM frame
Ping #233

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-10-24 19:30:11 +01:00
8ddbebb5d1 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 20:24:20 +01:00
2d28ab6032 options: remove --respect-prop-shadow
A quick search on GitHub showing the _COMPTON_SHADOW is actively being
used (most noteably, by polybar). It is not a difficult thing to support,
and it doesn't have that much runtime overhead. So remove the option
that guards this feature, make it enabled by default.

(Side note, I saw lots of people putting this option in their config
files, but this is actually a command line only option.)

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-10-22 20:45:21 +01:00
583cf35bed Fix compiler warnings in release builds
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-10-12 15:12:17 +01:00
1ca01ec456 Make sure window cannot enter fading when unredirected
Firstly, this breaks the assumption that when we redirect the screen,
all window is either mapped or unmapped, causing a assertion failure.

Secondly, if transition window into fading when the screen is not
redirected, the fading will not progress until the screen is redirected,
probably not the desired result.

Fixes #246

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-10-11 18:01:13 +01:00
f493447b33 win: clear PIXMAP_STALE in {unmap,destroy}_win_start
Also make sure unmapped/destroyed windows don't have PIXMAP_STALE flag
set.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-09-29 00:09:40 +01:00
0fc6f9aee2 core: bind shadow immediate in initialize_backend
This simplifies the logic a bit since we know a shadow is always bound
(if needed) when the screen is redirected.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-09-29 00:04:09 +01:00
33a106e254 win: don't ignore SHADOW_STALE flag on unmapped windows
Previously all image stale flags are ignored when processing an unmapped
window. If a window gains a shadow during its fading out transition, the
shadow flag will be set, but shadow won't actually be generated, causing
a NULL pointer dereference during render.

Fixes #239

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-09-23 21:52:26 +01:00
c85c9ef1cc win: set session::pending_updates in win_set_shadow
Otherwise shadow won't get generated in next critical section, causing
NULL pointer dereference or assertion failure in next render.

Partially fixes #239

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-09-23 21:52:11 +01:00
8628e498c5 win: rename win_get_name to win_update_name
Make explicit the fact that it modifies the win struct.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-09-23 21:22:17 +01:00
0063738754 Merge pull request #236 from liskin/memleaks
fix a few memory leaks reported by valgrind
2019-09-20 14:52:17 +00:00
23421b2ff8 win: fix memory leak in fill_win
Fixes the following memory leak reported by valgrind:

    1,056 bytes in 24 blocks are definitely lost in loss record 83 of 111
       at 0x483577F: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
       by 0x49DB0DD: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
       by 0x49D8FB4: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
       by 0x49DA63E: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
       by 0x49DA751: xcb_wait_for_reply (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
       by 0x11FD5B: fill_win (win.c:1165)
       by 0x117CE6: handle_new_windows (compton.c:1266)
       by 0x118065: _draw_callback (compton.c:1333)
       by 0x1184D0: draw_callback (compton.c:1426)
       by 0x49BF292: ev_invoke_pending (in /usr/lib/x86_64-linux-gnu/libev.so.4.0.0)
       by 0x49C3344: ev_run (in /usr/lib/x86_64-linux-gnu/libev.so.4.0.0)
       by 0x11AD65: session_run (compton.c:2226)

This one out of multiple code paths forgot to free the structure. Yeah,
manual memory management is hard. :-)
2019-09-20 10:15:59 +02:00
3766aa2c79 win: make sure delayed image update is always used
Convert several places where the window image is bound/unbound directly
to use image flags. Make sure window image updates only happen in one
place.

Remove win_bind_image function since its no longer used after this.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-09-20 02:22:48 +01:00
39a609acb0 event: do delayed window mapping
This remove the only case where map_win_start is called outside of the
X critical section.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-09-20 02:22:48 +01:00
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
16bff8ff41 win: add managed_win_internal
Which includes the pending update flags for the window.

Using an internal struct makes sure the window update flags are opaque outside
of win.c

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-09-20 02:22:15 +01:00
b9bf4fed60 win: rename some functions
rename map_win, unmap_win, destroy_win to map_win_start,
unmap_win_start, destroy_win_start respectively. To clarify their
intended functions. Also rename the corresponding finish_* functions to
*_finish so they are consistent.

Also some very minor code clean ups.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-09-20 02:22:15 +01:00
fd570e1b78 win: split unmap_win into unmap and destroy
Instead of doing both unmapping and destroying in the same function,
since that complicates the logic.

Also since now destroy_win handles both the managed and unmanaged cases,
remove destroy_unmanage_win function.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-09-20 02:22:11 +01:00
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
1549997811 win: remove map_win_by_id
Since it has only one user.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-09-20 01:24:57 +01:00
5787c17ebe Promote some log_trace to log_debug
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-09-19 17:23:48 +01:00