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).
-- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
