For big windows, their shadow images might exceed the maximum request
length limit of Xorg. libxcb will shutdown the connection to X server if
we try to send that image. So we have to break the image apart and send
it piecemeal.
In the future we probably should migrate to MIT-SHM.
Fixes#255#274
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Transparent windows usually blends on top of other windows, this commit
adds an option to make transparent windows clip other windows like
non-transparent windows do.
Closes#265
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Instead of allocating new textures everytime gl_average_texture_color is
called, we keep two textures per gl_image and reuse those.
Doing this significantly improves CPU usage on AMDGPU driver for some
reason. But in general, less texture allocation is always better.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
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>
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.
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>
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>
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>
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>
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>
