950247 - Calculate FPS by tracking Frame Requests at the refresh driver to the compositor

Status: RESOLVED WONTFIX

(Core :: Graphics, defect, P2)

Description

[Mason Chang [Inactive] [:mchang]]

Instrument the point from when the refresh driver ticks for a new frame to when the compositor finishes a frame and delivers the output to the GPU. This should give us a more accurate picture of FPS for synchronous scrolling.

Comment 1

[Mason Chang [Inactive] [:mchang]]

Attachment: WIP - Calculate FPS From Task Loop Recv Message to EndFrame

Just a work in progress to see if I'm on the right track (Lots of prototype and ugly code). I still need to make sure we're doing it in less than 16.6 ms, but for now we calculate number of frames we finished per second. Just a few questions:

1) Is this the right place? We're measuring from the point we get a DispatchMessage the Parent to the point the Compositor backend finishes the frame and before we do SwapGL. Or should we instrument the places where the actual composite message is created and put on the message loop?

2) I see that a lot of places we instrument are close to the same places as COMPOSITOR_PERFORMANCE_WARNING. Why can we not use that information instead?

Thanks!

Comment 2

[Geo Mealer [:geo] -- This account is inactive after 2015-07-07]

Mason, will this be generally useful for measuring things like swipe transitions between home pages, etc, or is this specific to scrolling?

Comment 3

[Mason Chang [Inactive] [:mchang]]

Geo, I think it should help with every frame that's being generated, so even things like swipe transitions should be measurable here.

Comment 4

[Geo Mealer [:geo] -- This account is inactive after 2015-07-07]

Nice, sounds great!

Comment 5

[Benoit Girard (:BenWa)]

This patch doesn't do what is described in the bug. This patch seems to calculate something that is roughly what the transaction FPS counter shows. How does this differ from it?

Comment 6

[Mason Chang [Inactive] [:mchang]]

Attachment: fps.patch

Ok let's try again. Hopefully I understand the problem better this time :). The current patch counts the number of frames painted based on when nsRefreshDriver::Tick is called. Once ~1 second has passed, we print out the FPS. Is this a better approach and reflective of the bug name? Thanks! If so, I'll go clean it up a bit.

Comment 7

[Benoit Girard (:BenWa)]

This is the transaction FPS. Let's discuss this in TPE next week since we're misunderstanding each other here.

Comment 8

[Mason Chang [Inactive] [:mchang]]

After our discussion in TPE, this would only be valid on sync scrolling. For APZ, we will measure painting times + compositor FPS bug 990835. Resolving as wontfix.