Result from tracing

Methods

Count the number of Jank(ZeroRasterEndInVsyncInterval) synthesized events (generated by my script).

Alternatively, manually look at each and every vsync interval. If there is no GPURasterizer::Draw ending in that interval, we will observe one jank.

Results

Well, for this tracing data, zero jank happens (no "Jank" in the following screenshot). So it is exactly 60FPS.

However, it is definitely not always the case. For example, we have seen in the video section that it is only ~58FPS. As discussed there, this can be caused by bugs of this package, and/or other factors unrelated to build/layout slowness. Moreover, I suspect the good data here is because, in order to keep the tracing file small in git repo, I choose to record the first scroll; however, in that section, it is (for example) 10th scroll. Therefore, I guess GC pressure will be much larger there. Anyway, these two are only samples - if you see a problem in real world, don't hesitate to submit an issue and discuss!

Example: How does a jank look like

Luckily, there is a bug that I have not fixed, and it affects the time range 2800ms-3400ms, which is indeed the time before the main scrolling happens, causing a jank (and a lot of LargeLatency_PreemptRender warning). So we can have a look how a jank looks like here.

Look at the figure below, we see a Jank(ZeroRasterEndInVsyncInterval) in the 2938-2955ms frame. Clearly, during these 16.67ms, there is no ending of GPURasterizer::Draw. In other words, no content is provided to the screen, so we will have a jank.

(May discuss LargeLatency_PreemptRender which is a good hint of implementation and usage bugs later)