Correctly track saved surfaces during multiple transactions

Fixes #2364.

Suppose a view is 600px wide, and we tell it to resize to 601px during a
resize operation. We create a transaction, save the 600px buffer and
send the configure. This buffer is saved into the associated
instruction, and is rendered while we wait for the view to commit a
601px buffer.

Before the view commits the 601px buffer, suppose we tell it to resize
to 602px. The new transaction will also save the buffer, but it's still
the 600px buffer because we haven't received a new one yet.

Then suppose the view commits its original 601px buffer. This completes
the first transaction, so we apply the 601px width to the container.
There's still the second (now only) transaction remaining, so we render
the saved buffer from that. But this is still the 600px buffer, and we
believe it's 601px. Whoops.

The problem here is we can't stack buffers like this. So this commit
removes the saved buffer from the instructions, places it in the view
instead, and re-saves the latest buffer every time the view completes a
transaction and still has further pending transactions.

As saved buffers are now specific to views rather than instructions, the
functions for saving and removing the saved buffer have been moved to
view.c.

The calls to save and restore the buffer have been relocated to more
appropriate functions too, favouring transaction_commit and
transaction_apply rather than transaction_add_container and
transaction_destroy.

0 files changed, 0 insertions, 0 deletions