1337687 - 25.4% of compositor thread time is spent running "antifilldot8" algorithm

Status: NEW

(Core :: Graphics, defect, P5)

Description

[Jukka Jylänki]

Attachment: antifilldot8.png

STR:

1. Enable wasm with pref javascript.options.wasm to true
2. Visit https://s3.amazonaws.com/mozilla-games/tmp/2017-02-07-PlatformerGame/PlatformerGame-HTML5-Shipping.html?novsync

Looking at a geckoprofile of the compositor thread while playing the game on a high end 80-core PC with Linux Mint 18 and GTX 980Ti, 21.9% of total execution time is spent running an "antifilldot8" algorithm, which sounds like some kind of software rasterization/blit loop in Skia.

The page should not have any special software composited parts, but it is all WebGL, so should be well GPU accelerated? Is the page doing something unexpected, and if so, any recommendations on how to avoid this? The test system has a 1920x1080 display while browser was windowed and covered about 80% of the screen during the test. A quarter of one thread's time allotment sounds a bit suspicious here.

Comment 1

[Lee Salzman [:lsalzman]]

The first issue is that we do not do any GL compositing on Linux because at current it is too buggy to enable by default. So for that reason alone everything is composited in software.

For WebGL, We do a readback to a shmem to send WebGL stuff to the compositor because currently we have no reliable way to do otherwise, even with xrender, since GLXPixmaps turned out to be too unreliable to enable by default as well. So that the other reason this is just being composited in software.

Comment 2

[Clemens Eisserer]

I wonder what is worse: Exposing broken drivers on a few systems, therefore creating preasure to fix those issue which would benefit the whole linux graphics stack, or doing a readback of a GL surface in order to be able to perform composition in software?