For improved deterministic blocking, we actually were allowing the full compositor to run (unecessarily) when the screen was off. whereas this change effectively allows the client to continue to render, but the compositor doesn't run (in effect dropping the frame)...if you'll remember apps keep rendering just a bit after the screen goes off with Qt5.2, this is b/c we stopped "blocking indefinitely" but there is a bit of a race between the screen turning off & either the side channel (qt's window exposeEvent) communication being acted upon by the app or the app life cycle mechanism kicking in to halt the render.
As for the visibility i/f addition, its actually related to the Qt5.2 side channel communication. We want to add an event to cleanly propagate when a surface looses visibility, whether its occluded (e.g. "pushed back" in the app stack ubuntu phone) or the screen has turned off. On Thu, Jun 12, 2014 at 3:17 PM, Roman Zonov <roman2...@yandex.ru> wrote: > Can you describe it? > > "landed improvement for deterministic blocking" > "began work on adding an interface for “visbility” of surfaces for clients" >
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
