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>
When matching against custom window properties or atoms perform the
matching against all available values using logical OR if the special index
`[*]` is specified. If no index is specified, we fall-back to the first
value.
This should help when an atom has multiple values and you only want to
check against any of these — e.g. hiding windows with state `hidden`:
`--opacity-rule "0:_NET_WM_STATE@[*]:32a *= 'HIDDEN'"` — without having to
explicitly specify each index separately or when the index is not known
in advance.
Updated the manpage with examples for hidden and sticky windows.
win_update_screen needs w->widthb/heightb, which is only updated in
win_on_win_size_change
Related: #554
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
fill_win only sets the pending geometry (aka the shadow geometry) of the
window, we have to wait for it to propagate to the real geometry before
we can update the screen.
Related: #554
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Since commit 95a64acf5a, fill_win doesn't
set the window geometry anymore, so we can't use it in
handle_new_windows.
However, we don't need to add damage in handle_new_windows anyway,
damage will be added later when the MAPPED flag is handled.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Consider these 2 cases:
* A window is mapped while fading out
* A window is mapped and damaged while fading out
From the perspective of map_win_start, these 2 cases look the same. The
window will has ever_damage = true in both cases. However, map_win_start
has to distinguish between these 2 cases, because at the end of
map_win_start, window in the first case cannot have ever_damage = true,
while window in the second case should have ever_damage = true.
Currently, map_win_start always clears ever_damage in both cases
(indirectly through win_skip_fading), which causes windows in the second
case to not be rendered when they should be.
This commit move clearing of ever_damage from unmap_win_finish to
unmap_win_start, so when map_win_start sees ever_damage = true, it's
always to second case. And to make sure windows which are fading out are
still rendered, we relax the ever_damage check in paint_preprocess to
also accept windows that are fading out. (see code comment for
explanation why this is fine)
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
