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.
This commit is contained in:
Tudor Brindus 2020-10-18 17:29:59 -04:00 committed by Simon Ser
parent 8355884fbd
commit cc8d318aa1

View File

@ -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;
}