>Are there details on what this actually means? e.g. don't we *have* to >paint when when we receive a WM_PAINT event, and usually we shouldn't at >other times?
To clarify, these patches split painting up into two steps: 1) Compute invalid regions, build display lists, layers and repaint the changed areas of our retained layers. 2) Composite the retained layers onto the screen. Previously both steps were done in response to the WM_PAINT event, now we do part 1 off the refresh driver, and just part 2 from WM_PAINT OMTC will move part 2 onto a separate thread entirely and the only thing we need to do in response to WM_PAINT will be notify the compositor to draw to the screen asap. >"Artificially" meaning "the computer has idle CPU and could issue >WM_PAINT at 60 fps but the OS decides not to?" Do we know why the OS >behaves in this way? I don't have any information on why the OS isn't sending WM_PAINT events as quickly as we request them. >Is this regression in Tp times matched by an improvement in perceived >performance because we're painting more often? If so, I think this >tradeoff makes sense (although I'd hope we had metrics which could >measure this perceived improvement). As mentioned before, these extra paints don't actually make it to the screen without OMTC, so unfortunately not. This should definitely be true once OMTC lands for desktop, and already true for android. I just measured the fps of our drawing (not necessarily compositing to the screen) while running tp5 and these patches increase it significantly (13fps -> 22fps). >I'm a little wary of just taking a 5-8% Tp hit though! Me too! --BDS _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
