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>
If a window is unmapped, then mapped to a different position on screen
before fade out is completed (when fading is not enabled, it has to be
mapped again in the same frame), the old window content is left on screen.
This is because when this happens, we didn't add the unmapping window to
damage.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Looks like an empty argument is now the same as no argument. And
circleci complains about argument missing.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Using opacity_t for opacity_old resulting in opacity being rounded to 0.
This is fine until the opacity reaches 0, where the opacity != opacity_old
check fails and the damage is not added.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
If window is closed when fading is not enabled, the window might be destroyed
before we can add the window extent to damage.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Yuxuan Shui