Should presentation-time discard feedbacks on every commit independent of buffer update?
Link to protocol: presentation-time.xml
The question is if commits should be "discarded" independently of content being updated by later ones or not.
For example after a commit C1 with a new buffer the client can still send more commits C2,...,Cn without new buffers before the buffer from commit C1 is presented on the hardware.
In this case (and assuming the client has asked for feedbacks each time before commits C1,...,Ck with some 1≤k<n) is the compositor supposed to send back discarded events for each commit C1,...,Ck?
The protocol speaks in this regard about "content updates" what is ambiguous:
One object corresponds to one content update submission (wl_surface.commit).
At the moment I don't directly have a leaning what would be better. I previously implemented it in KWinFT such that feedbacks of "replaced" commits are always discarded. Looking at my current work on presentation-time in Xwayland and some runtime tests I did Sway seems to do it the same way.
I believe it's easier for compositors to always discard but from my experience with Xwayland I would imagine it might be more demanding for clients to do it this way. It's basically about who needs to do the bookkeeping.