Blur-texture sampling has been changed to `CLAMP_TO_EDGE` in commit
4b0ff37b36 and to using the buffer
textures at screen position instead of texture origin in commit
89c18afac6.
When using the above approach, expanding the buffer textures by the same
amount as the damage region is not needed anymore, as we cannot render
more than the screen region anyways. Having larger-than-screen buffer
textures might lead to a slight darkening at the upper and right edges
since we don't necessarily trigger the `CLAMP_TO_EDGE` condition in the
intermediate steps. This becomes apparent when using dual-kawase at large
blur-strengths with light backgrounds.
These changes do not affect the general approach of rendering a
larger-than-window region with the blur to accommodate the necessary
increase in damage region.
Related: 6d646b543f
Explicitly set `xinerama_scr_regs` to `NULL` after calling free() to
avoid freeing them again.
Under normal operation we free the old xinerama screen region list on
root screen changes and allocate a new one with the updated regions.
On rare occasions — mainly reproducable by changing monitors while DPMS
is in standby — updating the region list might fail as for whatever
reason the xinerama extension is marked as inactive. This would leave
us with an invalid pointer to the already freed region list we would
then attempt to free again on the next root screen change.
Added the new `clip-shadow-above` configuration and wintype option.
These allow the user to select windows to clip from the shadow region of
other windows, i.e. don't paint shadows on top of them.
This should provide a more useful and userfriendly alternative to the
deprecated `shadow-exclude-reg` option — especially for docks and bars.
Changes to frame extents were only tracked if the frame was visible, but
we have to keep this information current even for invisible frames to
(not) render the correct area.
Use window geometry (width, height) including border-width as the base
for frame region calculation with `_NET_FRAME_EXTENTS`, instead of
including the extents themselves.
Fixes issues where the frame would get incorrectly blurred *outside* the
window area.
fixes: #413#590
related: fb3305fb9b
If the user has no access to the GPU, initialization of the GLX context
fails. In the legacy backend, this occurs BEFORE the session has been
successfully initialized.
At this point we cannot meaningfully filter xerrors as the session
hasn't been initialized yet. So we don't try to.
Force a 32-bit ARGB visual when cloning pixmaps for
`IMAGE_OP_APPLY_ALPHA`.
Fixes non-transparent frames for 24-bit windows (without alpha-channel)
even when using `frame-opacity != 1`.
fixes: #342
At least on nvidia, binding the textures from a glx pixmap to a
framebuffer results in `GL_FRAMEBUFFER_UNSUPPORTED`. Instead of using
binding the source texture to a framebuffer and using `glCopyTexImage2D()`
to copy into a new texture, explicitly render the source texture to the
new texture attached to a framebuffer.
Fixes black/invisible windows on nvidia with `frame-opacity != 1`.
see: #647
related: 2a60836a9b
Added more descriptive checks for framebuffer-completeness after adding
attaching textures (for the first time).
Also check for GL errors after `IMAGE_OP_APPLY_ALPHA`.
Currently there is some inconsistency in how image_op is implemented
across backends. The glx backend applies some of the image operations
lazily, and not always in the order the operations were made; while the
xrender backend applies the operations eagerly. This can lead to
different render result in some cases.
Instead of trying to preserving the order of operations, which would be
unnecessary, we re-model the API to better reflect the implementation.
We make it clear that setting the property doesn't change the image
data, and properties are only applied during composition and in a
specific order.
This makes sure the render result looks consistent across backends.
Should also improve the performance of the xrender backend, even if only
slightly.
Also distill out the property management code so they can be shared.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
\b \? \+ \| are GNU extensions to sed
In BRE (Basic Regular Expressions) there is no \? \+ or \|
In ERE (Extended Regular Expressions) there is ? + and |
To specify sed to use ERE, specify the -E flag.
GNU grep does not distinguish between BRE and ERE, but other
implementations do. To make grep use ERE instead of BRE, specify
the -E flag.
The GNU extension \b has no equivalent in either BRE or ERE.
So, in line number 216, I used the whole initial expected output.
For quick reference (n/a means 'not available') -
GNU BRE | POSIX BRE | POSIX ERE
-------------------------------
\( | \( | (
\) | \) | )
\? | \{0,1\} | ? or {0,1}
\+ | \{1,\} | + or {1,}
\| | n/a | |
\b | n/a | n/a
Potential use: to read the border color of a window, so we could draw
rounded border when we round the corners of the window.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
