1690840 - modified testcase from bug 1690835 takes a lot of CPU in WR compared to non-WR (35% of WRRenderBackend spent in AlphaTextureTarget)

Status: RESOLVED FIXED

(Core :: Graphics: WebRender, defect)

Description

[Mayank Bansal]

use WR in Nightly
Open the attached testcase

ER: low CPU use
AR: high CPU use

All I changed from the original testcase from bug 1690835 is to change the CSS like so :

Original : font-size: 50px;
Modified : font-size: 250px;

Comment 1

[Mayank Bansal]

Attachment: about:support

Comment 2

[Mayank Bansal]

Attachment: testcase.html

Comment 3

[Mayank Bansal]

https://share.firefox.dev/2MQnhXk

35% of WRRenderBackend spent in some AlphaTextureTarget

Comment 4

[Dzmitry Malyshau [:kvark]]

This is "DWriteGlyphRunAnalysis::CreateAlphaTexture" more specifically. I wonder if we are applying the transformations to the glyph themselves, instead of applying them post-rasterization in our shaders. Maybe Lee has thoughts.

Comment 5

[Lee Salzman [:lsalzman]]

Can you get a profile from non-WR that I can compare with?

Comment 6

[Lee Salzman [:lsalzman]]

My suspicion here is just that due to the large font size, you are seeing a different between how Skia and WR render large glyphs. Above a certain size threshold, Skia draws glyphs as paths, whereas WR continues to draw them as glyphs. We can't draw them as paths in WR because currently we don't have a GPU-accelerated solution for drawing paths in WR. This is most likely the cause of the divergence in CPU usage you are seeing, but I would have to see a comparison profile to be sure.

Comment 7

[Mayank Bansal]

non-WR : https://share.firefox.dev/2YPbhYR

Comment 8

[Mayank Bansal]

Attachment: non-wr about:support

Comment 9

[Lee Salzman [:lsalzman]]

It doesn't look like that profile has all the content process threads in them. Can you try getting a profile with the Firefox Graphics preset in the profiler?

Comment 10

[Mayank Bansal]

new profile : https://share.firefox.dev/2YNhDYP
the content process has pid of 15116
(The previous profile had the cintent process, but the profiler chose to hide it by default. Maybe because it had no activity?)

Comment 11

[Mayank Bansal]

(In reply to Mayank Bansal from comment #7)

non-WR : https://share.firefox.dev/2YPbhYR

Modified the profile to show the relavent content process : https://share.firefox.dev/3jmGJqR

Comment 12

[Lee Salzman [:lsalzman]]

Hiro, it looks like we're getting animation compositor animation and no invalidation here in the layers case, but we get invalidation in the WR case, any idea why?

Comment 13

[Mayank Bansal]

https://share.firefox.dev/3p1XVTB

This is fixed. Most probably by bug 1690835

Comment 14

[Hiroyuki Ikezoe (:hiro)]

(I wrote a comment but forgot to publish it, here is the comment, I was going to add Glenn in CC list and he fixed the issue! Wonderful!)
(here is the comment)

I am afraid I don't know about the invalidation stuff either on WR or non WR. CCing Glenn (though I assume why Lee asked me is that he wanted to know the reason why non WR doesn't invalidate).