mirscreencast still captures (forces composition) even if there are no clients rendering

Sounds like a fix would resolve bug 1294361 too.

I think it's OK (even preferred) for screencasting to capture at a steady rate (as much as possible at least), regardless of whether something is changing on screen or not. What's the point of a screencast with an unstable frame rate (e.g. frameN from frameN+1 being 2 seconds apart because nothing changed)? Screencasting does not fall under the same performance/power restrictions we have for normal compositing.

The alternative would be to timestamp frames (which I think was brought up at some point in our stand-ups), although I am not sure how easy it would be to convert the resulting stream to something watchable.

I'm undecided on this. Obviously dynamic frame rate (just observing real frames as they're scheduled) is most efficient but we cannot feasibly join up the resulting frames into a steady video without building-in support for variable-framerate video format encoding to the tooling. I think that would limit our options, aside from being quite complicated.

So yeah, we probably want to force capture at a steady frame rate.

Variable-framerate is a non-issue in most containers - all of them have duration tables built-in. I don't see why this would be "quite complicated".

I also disagree on the performance restriction since that's actually what's driving the submission of this bug especially on embedded devices with massive screen sizes such as the N10.

Just thinking about this more, we should allow both options. So maybe this bug should be an enhancement request to optionally capture only at scene changes.

It's complicated because linking to external video encoding libraries would be unacceptable. Hence we would have to do the encoding ourselves, making variable-framerate more complicated than constant frame rate.

- unacceptable
+ undesirable

I said that because Mir is growing dependencies too fast. But sometimes they're necessary.

Syncing task from Mir.