When going through the cached buffers, we only set buffer->busy on the first re-usable buffer we found.
In some cases, we will find more than one re-usable buffer. In this case, we select the "youngest" one (i.e the one most recently used, in the hopes that we can use damage tracking instead of re-rendering the entire buffer).
If the "current" buffer is younger than the previously detected, re-usable, buffer, then we unref:ed the previously selected buffer, and replaced it with the current one.
But, we did not sanitize the newly selected buffer. That is, we did not:
- set
buffer->busy
- clear its dirty region
- clear its scroll damage
That buffer would eventually get rendered to, and committed to the compositor. Later, the compositor would release it. And there, in our buffer_release() callback, we’d assert that buffer->busy was set. And fail.
@dankamongmen I haven't yet been able to reproduce the crash, but I'm fairly sure this is it. Any chance you can give this branch a spin?
Closes #844
When going through the cached buffers, we only set `buffer->busy` on the *first* re-usable buffer we found.
In some cases, we will find more than one re-usable buffer. In this case, we select the "youngest" one (i.e the one most recently used, in the hopes that we can use damage tracking instead of re-rendering the entire buffer).
If the "current" buffer is younger than the previously detected, re-usable, buffer, then we unref:ed the previously selected buffer, and replaced it with the current one.
But, we did not sanitize the newly selected buffer. That is, we did not:
* set `buffer->busy`
* clear its dirty region
* clear its scroll damage
That buffer would eventually get rendered to, and committed to the compositor. Later, the compositor would release it. And there, in our `buffer_release()` callback, we’d assert that `buffer->busy` was set. And fail.
@dankamongmen I haven't yet been able to reproduce the crash, but I'm fairly sure this is it. Any chance you can give this branch a spin?
Closes #844