Code review comment for lp://staging/~afrantzis/mir/non-blocking-swap-buffers

> 216 + if (r->visible())
> I intend on removing visible and the saved resources vector soon anyways.

Does that mean that scene->generate_renderable_list() will return only renderables that have buffers for rendering?

@saved_resources

I guess the plan is to keep buffers "alive" using some other mechanism. Will we be able to use that mechanism from outside the DisplayBufferCompositor, or do we need to continue use the saved resources vector in the BufferConsumingThread?

220 + wait_until_next_vsync();

wait_until_next_fake_vsync() ?

> given mc::BufferStream::allow_framedropping(), which is set by the client, it seems strange drop frames via
> BufferConsumingFunctor if we decide not to consume the buffer. Shouldn't problems with swapping and ordering be
> solved more in the BufferStream/SwitchingBundle?

I thought a bit about this (but not much really), but couldn't find a satisfactory way to do it in BufferStream/SwitchingBundle. The main issue is that this is not unconditional framedropping, but "framedropping" only if not rendered, which is only known at the compositor level. Even if we find a way to do it in BufferStream/SwitchingBundle, we need to take into account the complexity we are going to add to an already complex component. In any case, I am open to ideas :)

> another thought:
> could we do this in one loop/thread? (and only generate the renderlist once?)

We need to support the cases of multiple active monitors and of no active monitors (e.g. screen off on android). For multiple active monitors we could do as you propose if we have a way for the display_buffer_compositor to return all the surface buffers it didn't consume. Note, however, that in terms of consumed buffers it's almost the same as (or worse than) having the extra thread proposed in this MP. Imagine for example two compositing threads T1,T2 for two outputs and two sets of surfaces A (visible on first output) and B (visible on second output). If we consume hidden surfaces in the compositing threads then T1 will consume AUB and and T2 will consume BUA. With an extra thread T1 consumes A, T2 consumes B and the extra thread consumes AUB. So both ways consume A twice and B twice. For more than two outputs however, consuming in the compositing thread themselves leads to more consumptions than with the extra thread.

For no active monitors and hence no compositing threads, we need the extra consuming thread anyway, so I decided to use it unconditionally, since it provides the behavior we want and it's conceptually simple (essentially just another (fake) output from the POV of our buffer handling).

Granted that for only one output what you describe is a win: we only use one thread and consume the hidden buffers only once. However, it does add some complexity that I wanted to avoid at this point, since this is a matter of optimization not correctness. I am fine with optimizing this use case when things have settled.