A Big Performance Fix Is Pending For WebKit / WPE On Wayland
Lord noticed that when a frame exceeds the 16.67ms / 60 FPS rendering budget, WebKit/WPE with the Wayland back-end will hard-drop to rendering at 30 FPS while that is not the case with other browsers. In analyzing the situation he summed it up as:
In summary, there are two identified bugs, or at least, major differences in behaviour with other browsers here, both of which affect both fluidity and synthetic test performance. I’m not too concerned about the latter, but that’s a hard sell to a potential client that’s pointing at concrete numbers that say WebKit is significantly worse than some competing option. The first bug is that if a frame goes over budget and we miss a screen refresh (a vsync signal), we wait for the next one before kicking off rendering again. This is what causes the hard drop from 60fps to 30fps. As it concerns Linux, this only affects the Wayland WPE backend because that’s the only backend that implements vsync signals fully, so this doesn’t affect GTK or other WPE backends. The second bug, which is less of a bug, as a reading of the spec (steps 9 and 11.10) would certainly indicate that WebKit is doing the correct thing here, is that the timestamp given to requestAnimationFrame callbacks is the current time and not the vsync time as it is in other browsers (which makes more sense for timing animations).
There are currently unmerged patches worked on by Lord for addressing these performance issues with WebKit/WPE on Wayland.
While a synthetic test, with the two fixes worked on it takes the MotionMark browser benchmark score from 35 up to 233... Quite the improvement and the rendering latency results are also in much better shape.
More details on Lord's blog.
Add A Comment
