I uncovered a problem while investigating a tresize regression. The root of the problem is illustrated in the attached timing diagram. If there are paints in both the UI process and content process in the same vsync interval (e.g. because the window resized, but could be lots of other reasons), then the compositor thread will receive two SetDisplayList messages (one from each process). Those two SetDisplayList messages will each trigger a scene build transaction in WR, and both of those scene builds run on the scene builder thread, serially. So in non-WR, the rasterization step for this scenario happened in parallel on the UI process main thread and content process main thread, but with WR, the scene building happens serially. This loss of parallelism can result in missing frame budgets and increased latency in getting stuff to the screen.

Some relevant discussion at https://mozilla.logbot.info/gfx/20180627#c14940763

If the lion's share of scene building time is spent in rasterization, then I suppose the hope is that parallelization across tiles will save us. If scene building is slow for other reasons, then we should speed up those other parts. Parallelizing rasterization within a single scene rather than across scenes will still be slower if there aren't enough tiles to saturate all CPU cores, though.

If we're passing our release criteria we can probably postpone this to after the MVP.

The problem seemed to be addressed by the followings. https://github.com/servo/webrender/pull/3043 https://github.com/servo/webrender/pull/3052