Open Bug 1337687 Opened 3 years ago Updated 3 years ago

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


(Core :: Graphics, defect, P5)





(Reporter: jujjyl, Unassigned)



(Whiteboard: [gfx-noted])


(1 file)

Attached image antifilldot8.png

1. Enable wasm with pref javascript.options.wasm to true
2. Visit

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.
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.
Depends on: 1323284
Priority: -- → P5
Whiteboard: [gfx-noted]
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?
You need to log in before you can comment on or make changes to this bug.