When should a nested server first post a buffer?

[Alan Griffiths]

On 29/05/15 04:26, Daniel van Vugt wrote:
> Sorry for the confusion. Yes it's just a bug that needs fixing...
>
> If one frame has been posted then you need to take it because you can
> never predict how long before a second one arrives, if at all.

For clarity there are multiple bugs:

/1/ We composite when a surface is created - this leads to a nested
server posting a buffer with no content.
/2/ USC throws a buffer away as a workaround. Throwing a buffer away is
also a bug.

Having looked at the LegacySceneChangeNotification code it is simple to
fix the specific case of composite when a surface is created. However,

/3/ there are a host of cases in LegacySurfaceChangeNotification where
we would composite unnecessarily for surfaces that are not visible. For
example, the mir_demo_client_basic example in the original post triggers
composition when a surface that has never posted and is not visible is
destroyed.

I'll MP some improvements to Legacy*ChangeNotification to address /1/
and /3/ and then remove the workaround from USC.

The only disagreement on this thread seems to be whether or not
mir_demo_server should clear the background when started. I propose to
take the easier approach of retaining the existing behaviour (of not).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20150601/3afaa365/attachment.html>