Scroll down https://wiki.js.org/ using touchpad.

Profile: https://share.firefox.dev/35Q6yun

There's a big chunk in NtGdiDdDDIWaitForSynchronizationObjectFromCpu

The shader time is mostly in:
brush_image_ALPHA_PASS_ANTIALIASING_REPETITION_TEXTURE_2D_frag::swgl_drawSpanRGBA8,
brush_linear_gradient_ALPHA_PASS_frag::brush_fs
cs_clip_rectangle_FAST_PATH_frag::run

Asif, can you try toggling gfx.webrender.software.d3d11 and see whether it works better with true or false?

Jeff, it works a bit better when gfx.webrender.software.d3d11 is false.

Non-idle percentages as of e5e734f4fc19 (2021-1-21):

• 28% brush_image_ALPHA_PASS_ANTIALIASING_REPETITION_TEXTURE_2D_frag
• 16% cs_border_solid_frag
• 9% draw_quad (can't tell which shader, or which call from draw_texture_cache_target)
• 7% _memmove_avx_unaligned_erms < scale_blit < Composite
• 6% brush_solid_ALPHA_PASS_ANTIALIASING_frag
• 5% cs_clip_rectangle

This spends almost all its time in the linear repeat fast-path set up in bug 1686244. This seems due to the scrolling image background it has lower on the page.

Given that we do at least try to optimize that case, I would almost close this bug, however, we might be able to do a little bit better here in detecting if the section of texture we're drawing actually has to repeat or not and invoking the non-repeat fast-paths for it.

Bug 1700206 cleaned up the repeat handling, for the tangential reason of supporting tile repeat without regressing performance, to at least try to go through the normal linear sampling fallback when possible, which should yield a little bit of a speed boost for this case over the previous implementation of repeat sampling.

This reorganizes the blendTextureLinear code so that linear-repeat filtering
can reuse the linear filtering fast-paths. Otherwise, linear-repeat filtering
would previously only use the linear filtering fallback, when some patterns
like repeating background images are easily accelerated by these extra fast-paths.

https://hg.mozilla.org/mozilla-central/rev/dcc9ca0ad46e