SUMMARY It looks like the compositor is asking clients to perform a redraw without releasing surface buffers. See here: https://github.com/ii8/havoc/issues/37 STEPS TO REPRODUCE 1. Install havoc https://github.com/ii8/havoc 2. Run havoc and move the window out of bounds upwards OBSERVED RESULT The wayland client cannot redraw because no surface buffers have been released by the compositor, but still a frame callback is sent by the compostior. EXPECTED RESULT The wayland protocol specification states: "A server should avoid signaling the frame callbacks if the surface is not visible in any way, e.g. the surface is off-screen, or completely obscured by other opaque surfaces." So either the compositor should not signal frame callbacks if the surface is offscreen or, if it is onscreen, it should release a buffer beforehand(at least that is the only way it makes sense to me) so that the double-buffering mechanism works properly.
``` if (!term.buf[0].busy) buf = &term.buf[0]; else if (!term.buf[1].busy) buf = &term.buf[1]; else abort(); ``` there are cases when kwin can hold all two buffers and send a frame callback after finishing a compositing cycle. you must not make assumptions when the compositor decides to release buffers. if the surface gets offscreen (e.g. window got minimized), kwin will not release the attached buffer because the buffer may be needed to draw the thumbnail of the window in the task manager
>if the surface gets offscreen (e.g. window got minimized), kwin will not release the attached buffer because the buffer may be needed to draw the thumbnail of the window in the task manager Yes, but in this scenario the wayland spec says the compositor should not send a frame callback. (Also isn't just the more recent buffer enough? There are two) But I just made this report to make you aware of the issue and the spec says "should" instead of "must" so feel free to close this if you want to keep this behaviour.
>Yes, but in this scenario the wayland spec says the compositor should not send a frame callback Right, we both have an invisible otherwise harmless bug and that together is forming a visible harmful bug. Both need fixing. >if you want to keep this behaviour. We don't /want/ to keep the behaviour, it was important for us to not implement it due to a Qt bug at the time and they make up most our clients. I think we might be able to revisit this now though. I'll leave this open to remind me us to do so. You should also reopen yours.
> Right, we both have an invisible otherwise harmless bug and that together is > forming a visible harmful bug. > Both need fixing. I agree, I've already fixed mine before making this report, the bit with the abort() is old code. I just opened this to let you know, not because the visible harmful bug was still happening.
It seems like havoc is working now, right?
Sry for late response, I used a throwaway for this forum, I will respond fast on github. havoc prints warning messages if the compositor tells it to redraw without releasing a buffer first. If KDE still does that it's not ideal but the user won't notice if the window is off-screen at least. The situation hasn't changed since the initial post AFAIK unless there has been a change in the compositor, steps to test are in the OP.
Clients can't assume only two buffers are enough, and the compositor may send frame callbacks for any arbitrary reason at any time. If the client makes assumptions about either of these things, that's a client bug that needs to be fixed in the client