-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Atomic layout updates #2072
Merged
Merged
Atomic layout updates #2072
Changes from 9 commits
Commits
Show all changes
39 commits
Select commit
Hold shift + click to select a range
59c9488
WIP: Atomic layout updates ground work
RyanDwyer f9e6d70
Make main properties be the pending state
RyanDwyer bb66e6d
Refactor everything that needs to arrange windows
RyanDwyer 9e96cfd
Merge remote-tracking branch 'upstream/master' into atomic
RyanDwyer 645bf44
Merge remote-tracking branch 'upstream/master' into atomic
RyanDwyer 1c89f32
Preserve buffers during transactions
RyanDwyer 38398e2
Implement atomic layout updates for tree operations
RyanDwyer b11c919
Merge remote-tracking branch 'upstream/master' into atomic
RyanDwyer 32b865e
Fix crash when deleting last child in a tabbed or stacked container
RyanDwyer f08a30d
Force transactions to complete in order
RyanDwyer 33e03cb
Fix crash related to stacks and tabs
RyanDwyer b864ac0
Fix crash when unmapping a view with reapable parents
RyanDwyer b6a238c
Fix crash when running move <direction> in an empty workspace
RyanDwyer 1549fb7
Implement atomic layout updates for xwayland views
RyanDwyer a3976e2
Fix another crash when moving out of stacks or tabs
RyanDwyer 289d696
Implement transaction timings debug
RyanDwyer c371ff3
Implement per-configure debug timings
RyanDwyer 9b15e81
Fix potential crash when fullscreen view unmaps
RyanDwyer beacd4d
Rename progress_queue to transaction_progress_queue
RyanDwyer 7a922c6
Damage output when a fullscreen view unmaps
RyanDwyer 50190bc
Rename view's free callback to destroy
RyanDwyer e8001e6
Damage output when views toggle fullscreen
RyanDwyer 0085f64
Remove timer when transaction destroys
RyanDwyer 834805f
Fix crash when disconnecting output
RyanDwyer 93696b7
Fix crash when closing output window from outer session
RyanDwyer a7b3f29
Remove incorrect assertion and supporting code
RyanDwyer 61c1187
Fix nitpicks
RyanDwyer be86d3a
Remove transaction_add_damage
RyanDwyer 8773ed3
Fix memleak in container_get_box
RyanDwyer e6829c5
Move unsetting of view->surface into view_unmap
RyanDwyer 9652529
Allow views to skip configures
RyanDwyer e8fb6b3
Fix crash when moving last child of a container to workspace or output
RyanDwyer d7169ee
Replace list_empty with a simple alternative
RyanDwyer 3c81a90
Add comment about usage to arrange_windows declaration
RyanDwyer a2fbb20
Merge remote-tracking branch 'upstream/master' into atomic
RyanDwyer 3a6ed51
Render saved buffers with the surface's dimensions
RyanDwyer 96c8c02
Fix flash of background when xwayland views are mapped
RyanDwyer fc6fde7
Fix compile error
RyanDwyer e396af8
Merge remote-tracking branch 'upstream/master' into atomic
RyanDwyer File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,60 @@ | ||
#ifndef _SWAY_TRANSACTION_H | ||
#define _SWAY_TRANSACTION_H | ||
#include <wlr/render/wlr_texture.h> | ||
#include "sway/tree/container.h" | ||
|
||
/** | ||
* Transactions enable us to perform atomic layout updates. | ||
* | ||
* When we want to make adjustments to the layout, we create a transaction. | ||
* A transaction contains a list of affected containers and their new state. | ||
* A state might contain a new size, or new border settings, or new parent/child | ||
* relationships. | ||
* | ||
* Calling transaction_commit() makes sway notify of all the affected clients | ||
* with their new sizes. We then wait for all the views to respond with their | ||
* new surface sizes. When all are ready, or when a timeout has passed, we apply | ||
* the updates all at the same time. | ||
*/ | ||
|
||
struct sway_transaction; | ||
|
||
/** | ||
* Create a new transaction. | ||
*/ | ||
struct sway_transaction *transaction_create(void); | ||
|
||
/** | ||
* Add a container's pending state to the transaction. | ||
*/ | ||
void transaction_add_container(struct sway_transaction *transaction, | ||
struct sway_container *container); | ||
|
||
/** | ||
* Add a box to be damaged when the transaction is applied. | ||
* The box should be in layout coordinates. | ||
*/ | ||
void transaction_add_damage(struct sway_transaction *transaction, | ||
struct wlr_box *box); | ||
|
||
/** | ||
* Submit a transaction to the client views for configuration. | ||
*/ | ||
void transaction_commit(struct sway_transaction *transaction); | ||
|
||
/** | ||
* Notify the transaction system that a view is ready for the new layout. | ||
* | ||
* When all views in the transaction are ready, the layout will be applied. | ||
*/ | ||
void transaction_notify_view_ready(struct sway_view *view, uint32_t serial); | ||
|
||
/** | ||
* Get the texture that should be rendered for a view. | ||
* | ||
* In most cases this will return the normal live texture for a view, but if the | ||
* view is in a transaction then it'll return a saved texture. | ||
*/ | ||
struct wlr_texture *transaction_get_texture(struct sway_view *view); | ||
|
||
#endif |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(nitpick) Even if the implementation has been refactored to separate the rest of the destroy (now in surface notify destroy) and this function that is literally a free with extra checks, I'd keep the name
destroy
here as that's what we have all around in the impl vectors.You never know if in the future that'll need to do a bit more work again, and it won't be the first destroy function that just frees its argument :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I renamed it to
free
to keep it consistent with theview_destroy
andview_free
functions, andcontainer_destroy
andcontainer_free
. Destroying and freeing are now two different things. Destroying basically marks it as destroying, and when it's no longer in a transaction it gets freed.When a surface wants to destroy itself, we must unregister the wayland events before returning from
handle_destroy
because after we return the surface is no longer valid. But we can't free the view until later, when the view is no longer in a transaction. The non-atomic code in master does the unregistering and freeing of the view all in thedestroy
callback, using a call stack ofhandle_destroy -> view_destroy -> view->destroy()
.My branch takes a shortcut by unregistering the events in
handle_destroy
, andview_destroy
doesn't have to dive back into the implementation at all. I could add thedestroy
callback back and call it fromview_destroy
, but it needs to be separate from thefree
callback. The only benefit of doing it that way is the compositor could theoretically initiate a destroy without having the view requesting it. I'm not sure if that's against the protocol though, or if we'd ever use it.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I also think a
destroy
function which doesn't frees is confusing. I'd rather keep destroy and pick another name for the other function.