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>
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>
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>
win_get_name _updates_ the name of the window by querying the X server,
thus potentially changes the behaviour of the compositor when logging is
turned on (e.g. we could fail to detect window name changes, because the
name was blindly updated in a logging call without handling the name change).
We shouldn't do that.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
recheck_focus rejects focus of unmapped windows, so we have to make sure
pending maps of windows are processed before we call recheck_focus.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
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. :-)
Fixes the following memory leak reported by valgrind:
992 bytes in 31 blocks are definitely lost in loss record 81 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 0x118094: _draw_callback (compton.c:1335)
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)
by 0x11B005: main (compton.c:2308)
To prevent accidentaly reusing the freed structure, wrap it in a lexical
scope.
Fixes the following memory leaks reported by valgrind:
96 bytes in 1 blocks are definitely lost in loss record 54 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 0x14B266: detect_driver (driver.c:34)
by 0x119949: session_init (compton.c:1879)
by 0x11AEF0: main (compton.c:2285)
96 bytes in 1 blocks are definitely lost in loss record 55 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 0x14B266: detect_driver (driver.c:34)
by 0x11795E: redir_start (compton.c:1202)
by 0x115C76: paint_preprocess (compton.c:629)
by 0x1182BD: _draw_callback (compton.c:1380)
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)
Fixes the following memory leaks reported by valgrind:
32 bytes in 1 blocks are definitely lost in loss record 15 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 0x14B16F: detect_driver (driver.c:20)
by 0x119949: session_init (compton.c:1879)
by 0x11AEF0: main (compton.c:2285)
32 bytes in 1 blocks are definitely lost in loss record 16 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 0x14B16F: detect_driver (driver.c:20)
by 0x11795E: redir_start (compton.c:1202)
by 0x115C76: paint_preprocess (compton.c:629)
by 0x1182BD: _draw_callback (compton.c:1380)
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)
Also, free(randr_version) in the error path as well.
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>
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>
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>
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>
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>
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>
Instead of pointer to pointer. The two level of pointers were used to
inform the caller the window has been destroyed (pointer set to NULL).
Now, destruction of windows are now signaled by the return value, which
is marked `must_use`.
Problem with taking pointer to pointer is that they tends to pollute the
function signatures a little bit. And we are not using it well anyways.
A lot of the callers passes pointers to local variables to those
functions, so the information about window destruction doesn't actually
bubble up. So, we switch to use just one level of pointers instead.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
When a window has 0 opacity, it's rendering is skipped completely. Thus
its background isn't blurred.
This commit fixes that.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Dummy backends are backends that doesn't render anything on to the
screen or the target window. But they are still be useful for debug
purposes, and can be useful for other things too.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
blur_kernel_count could be none zero when user set a blur kernel but
didn't enable blur. In that case deinit_render will try to free
elements of blur_kerns_cache, causing a segfault because
blur_kerns_cache is never allocated.
Fixes#209
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
xerror handler might be called during XCloseDisplay, at which point
session_t is already destroyed, causing a segfault.
Ping #209
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Only render blur with transparency when window is fading in/out.
Otherwise, a window with a set opacity will always have a completely
blurred background.
Fixes#198
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
There were still some artifacts left when multiple semi-transparent
windows are stacked on top of each other.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Instead of rendering into the back buffer, render into a intermediate
texture.
This is a preparation for partial screen updating, which is necessary to
eliminate artifacts visible when using blur and use-damage together.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
In theory, it should be fine. But it causes mesa to stuck in
xcb_wait_for_special_event, indicating X connection setup issues.
Instead of investigating what went wrong in mesa, I choose to apply this
simple fix.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Doing this forces compton to blur every windows' background.
However, doing this can be beneficial, we will figure out a way
to do this properly in the future.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Previously, only the WM windows (window manager usually reparents the
application windows under its own window so it can manage them) are
checked for alpha channels. Some of the window managers (e.g. awesome)
acquire alpha channels for all of the WM windows, whether the underlying
application windows have alpha channel or not.
With this change, the application windows are also checked for alpha
channels. If a WM window has alpha but its child doesn't, only the WM
frame will be considered to be semi-transparent. Thus preventing some
unnecessary blurring.
Closes#191
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
During normalization of the kernel, the center element is added to the
sum twice, causing the resulting elements to be smaller than they should
be.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
This is done by extending the blur area internally when process
blurring.
Ping: #50, cause this fixes that problem but only when using the
experiemental backends.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
When enabled, the result will be redirected to a window, and compton
won't take over the screen.
Makes debugging easier.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
If screen is not redirected, we don't need to reinitialize the backend
when we got a root change event.
Fixes#189
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
To prepare for different blur methods, the blur interface of backends
has been splitted into two parts.
Now to use blur, a blur context must be created first; then, the blur
method should be called with the blur context created.
Updated the existing backends to the new interface. Also implemented
handling of the new blur options.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Also fill the center of parsed kernel with 1. This shouldn't change the
behavior of the old backends since they will modify the center of the
kernels.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Delay focus updates until critical section. Rational is that focus
events might arrive when the focused window hasn't been managed by
compton, result in that that window not being focused.
This commit makes compton mark focus update events, and only update
focus in critical section, after we managed all the new windows.
Fixes#177
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
glGetIntegerv(GL_NUM_EXTENSIONS) is only available since GL4.
(However glGetStringi(GL_EXTENSIONS) is available since GL3)
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Remove more unused stuff.
Also removed session::xinerama_scrs, since all the information we need
is covered by xinerama_scr_regs. Convert uses of xinerama_scrs to use
xinerama_scr_regs.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
It used to be unmap when we receive its MapNotify, but now since we discard
events received before we grab X server, that event it lost. But it
turns out we can just unmap it when it's first created, no need to wait
for the MapNotify.
Partially fix#160
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
When a window is reparented to the same parent again, we should just
move it to the top of the stack, instead of add it again.
Also a slight refactor restack_win.
Fixes#164
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Window flags can be set whichever backend we use, we will ignore then in
paint_preprocess. free_paint can be called whichever backend we use,
they just do nothing if we use experimental backends.
Others should rather just check if backend_data is NULL.
Making the code slightly more understandable, also making the eventual
removal of these checks easier.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Damage could have already happened at the time we call fill_win on a new
window. It's too difficult, or impossible, for us the find out if that
happened. So just blindly mark window as damaged.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Make sure X grab server is finished before calling x_discard_events in
session_init. Otherwise x_discard_events won't be able to discard all of
the events that were sent before we grab the server.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
A window might be mapped before we had the chance to start managing it.
So check to see if we should map a window after we call fill_win on it.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Create a "critical section" in draw_callback by grabbing the X server.
Delay the managing of newly created windows until we enter the cricial section.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Also, during session_init, discard old events after we grab the server.
If we don't do that, old, out dated CreateNotify will cause us to add
the window with the same id multiple times. Here is an explanation of
how that could happen:
1. compton connects to X
2. a new window created by someone else, X send us a CreateNotify
3. compton is initializing, so it didn't handle the event.
4. compton pulls a list of all windows from X. This will include that
window created in (2)
5. compton starts to handle event. it will handle the CreateNotify sent
in (2), thus adds the same window twice.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Instead of reusing add_win_above with the id of the window on the top
of the stack, we create a new function that takes a list_node.
Fix a problem when the window on the top of the stack is destroyed. Because
add_win_above search for windows from the hash table, it won't find that window
and returns NULL.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Currently compton handles window creation event by immediately query all
the information it needs and create a window struct with that
information. However, this is prone to race conditions.
In the future, we want to react to window creation event by creating a
placeholder in the window stack, and only query window information in a
critical section where the X server is grabbed by us.
This commit split struct win into two struct, one as placeholder, the
other for holding actual window information.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Previously we do window image update _after_ the to_paint checks.
Therefore the window image might failed to update after we decided to
paint it.
Do window image update before the checks.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Create a shadow image for a mapped window when it's shadow become enabled.
For unmapped window, the shadow image is created during mapping. Also,
if the window has IMAGE_ERROR flag, it won't be render anyway. So shadow
image won't be created in that case either.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Yuxuan Shui