CC'ing dev-platform since I accidentally removed it. ----- Forwarded Message ----- From: "Matt Woodrow" <mwood...@mozilla.com> To: "Benjamin Smedberg" <benja...@smedbergs.us> Sent: Friday, August 10, 2012 11:27:20 AM Subject: Re: Paint Timing Changes and Tp5
>When OMTC arrives, which thread will be running the widget event loop >and receiving WM_PAINT messages? Still the main gecko thread, we just don't paint synchronously in response to this event. Apparently this is fine. >This seems important. If the computer is running close to 100% CPU which >is why paints are being throttled, then we're just introducing extra >work for no benefit. We know that a significant portion of our user base >has relatively slow computers, and we don't want to be doing extra >painting that they will never see. Potentially true, but this is an intermediate state where we have clear plans going forward to fix this. >But if the problem is just that we aren't getting back to the event loop >"fast enough" and there is actually unused CPU capacity, then we should >ask our windows devs to look into this. Windows doesn't actually queue >WM_PAINT events in the event queue: it synthesizes them from the union >of invalidated areas when you get a message (using PeekMessage in our case). The problem seems to happen on all OS's (or least everything that we run tp5 on), so I don't think it's windows specific. >* Is this proposed change *required* for >display-list-based-invalidation? Or could we continue to paint on-demand >as we do today? At least for BasicLayers, yes. DLBI means that we don't know what the invalid area is (and thus can't request a widget repaint) until we've done display list/ layer building. If we wanted to delay actual painting until the event we'd either need to repeat display list building at that time (slow), or retain the display list and freeze the entirety of layout for that time period. I don't think either of these are feasible options. >* Are we sure that OMTC will fix the issue and ensure that we're not >doing extra unnecessary painting? Fairly sure, yes. >* In what cases does OMTC help? Does it help on single-core machines or >only multi-core machines? Both. B2G is doing compositing in a different process on single core phones with great results. >* Is it important to get this landed before OMTC so that we can discern >potential functionality regressions separately? Not necessarily, but we don't want to block DLBI on OMTC. DLBI fixes a lot of really bad over painting problems on complex animating pages, especially on fennec/b2g. >* Will OMTC land in this cycle, or is this a potential perf regression >that we'll see in a Firefox release before OMTC lands? Unlikely, most of the graphics team are still busy with mobile. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
