On 8/8/2012 9:16 PM, Matt Woodrow wrote:
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.
When OMTC arrives, which thread will be running the widget event loop
and receiving WM_PAINT messages?
"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.
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.
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).
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).
This doesn't seem like a useful metric. If we're drawing at 22fps but
compositing slower than that, then we're just wasting time drawing and
this is a real Tp regression.
* Is this proposed change *required* for
display-list-based-invalidation? Or could we continue to paint on-demand
as we do today?
* Are we sure that OMTC will fix the issue and ensure that we're not
doing extra unnecessary painting?
* In what cases does OMTC help? Does it help on single-core machines or
only multi-core machines?
* Is it important to get this landed before OMTC so that we can discern
potential functionality regressions separately?
* Will OMTC land in this cycle, or is this a potential perf regression
that we'll see in a Firefox release before OMTC lands?
--BDS
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
