From cc8d318aa1ab380166aa8183dba84a8d2a9ab2aa Mon Sep 17 00:00:00 2001 From: Tudor Brindus Date: Sun, 18 Oct 2020 17:29:59 -0400 Subject: [PATCH 1/3] transaction: make transaction collapsing smarter with > 2 views Sway maintains a list of pending transactions, and tries to merge consecutive transactions applying to the same views into one. Given a pending transactions list on views {A, B, C} of: A -> A' -> A'' -> B -> B' -> B'' Sway will collapse the transactions into just A'' -> B''. This works fine when doing things like resizing views by their border. However, when interactively resizing layouts like H[V[A B] C], we end up with pending transaction lists like: A -> B -> C -> A' -> B' -> C' -> A'' -> B'' -> C'' Previously, Sway would not be able to simplify this transaction list, and execute many more transactions than would be necessary (the final state is determined by {A'', B'', C''}). After this commit, the transaction list gets simplified to A'' -> B'' -> C'', resolving performance problems (that were particularly noticeable with high-refresh-rate mice). Fixes #5736. --- sway/desktop/transaction.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/sway/desktop/transaction.c b/sway/desktop/transaction.c index e186bf897..eac389917 100644 --- a/sway/desktop/transaction.c +++ b/sway/desktop/transaction.c @@ -358,11 +358,20 @@ static void transaction_progress_queue(void) { // If there's a bunch of consecutive transactions which all apply to the // same views, skip all except the last one. while (server.transactions->length >= 2) { - struct sway_transaction *a = server.transactions->items[0]; - struct sway_transaction *b = server.transactions->items[1]; - if (transaction_same_nodes(a, b)) { + struct sway_transaction *txn = server.transactions->items[0]; + struct sway_transaction *dup = NULL; + + for (int i = 1; i < server.transactions->length; i++) { + struct sway_transaction *maybe_dup = server.transactions->items[i]; + if (transaction_same_nodes(txn, maybe_dup)) { + dup = maybe_dup; + break; + } + } + + if (dup) { list_del(server.transactions, 0); - transaction_destroy(a); + transaction_destroy(txn); } else { break; } From 9e272a7986aa586a73951069aa76068e408a2c3f Mon Sep 17 00:00:00 2001 From: Ronan Pigott Date: Tue, 20 Oct 2020 12:09:38 -0600 Subject: [PATCH 2/3] tiling_resize: abandon resize if a sibling con dies --- sway/input/seatop_resize_tiling.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sway/input/seatop_resize_tiling.c b/sway/input/seatop_resize_tiling.c index 0dfafbd07..05be6e701 100644 --- a/sway/input/seatop_resize_tiling.c +++ b/sway/input/seatop_resize_tiling.c @@ -107,6 +107,9 @@ static void handle_unref(struct sway_seat *seat, struct sway_container *con) { if (e->con == con) { seatop_begin_default(seat); } + if (e->h_sib == con || e->v_sib == con) { + seatop_begin_default(seat); + } } static const struct sway_seatop_impl seatop_impl = { From 1be66c98f2c06add500bdb9d4b98b6183ab8141f Mon Sep 17 00:00:00 2001 From: Daniel De Graaf Date: Wed, 21 Oct 2020 18:11:29 -0400 Subject: [PATCH 3/3] commands/resize: don't consider 1px resizes to be invalid A "resize shrink width 1px" will cause grow_x to be 0 while grow_width is -1, incorrectly rejecting the command even though the resize is not a noop. Fix this by checking width/height instead of x/y. --- sway/commands/resize.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sway/commands/resize.c b/sway/commands/resize.c index 4038e331b..ca36e858d 100644 --- a/sway/commands/resize.c +++ b/sway/commands/resize.c @@ -224,7 +224,7 @@ static struct cmd_results *resize_adjust_floating(uint32_t axis, } else if (axis == WLR_EDGE_LEFT) { grow_x = -grow_width; } - if (grow_x == 0 && grow_y == 0) { + if (grow_width == 0 && grow_height == 0) { return cmd_results_new(CMD_INVALID, "Cannot resize any further"); } con->x += grow_x;