Open Bug 1710778 Opened 4 months ago Updated 2 months ago

Testcase is much more slower with animated text and faster if animated text is removed

Categories

(Core :: Graphics: WebRender, enhancement)

enhancement

Tracking

()

People

(Reporter: mayankleoboy1, Assigned: gw)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

Attached file Fast-No Text.html

Run both testcases individually.

The Fast with no text version is quite smooth, taking 8-10% CPU.
The slower testcase with text is slower, and uses a lot of CPU 240%-300% .

Profiles :
Fast testcase: https://share.firefox.dev/3y3MAbn
Slow testcase :https://share.firefox.dev/3tJzoVQ

If the perf difference is expected, feel free to INVALID.

Attached file Slow- With Text.html

When I run Slow- With Text.html on my PC, WRWorker threads were very busy for rendering glyph.

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

:gw, :lsalzman, can you comment to the bug?

Flags: needinfo?(lsalzman)
Flags: needinfo?(gwatson)
Blocks: wr-perf
Blocks: gfx-triage

We have some code in WR that avoids excessive glyph rasterization during pinch-zoom, which sounds like what we want to do here as well.

Jamie, do you think it'd be reasonable to extend this to apply the same logic for text runs that are animated? We could probably apply similar logic in the spatial tree, adding a method or flags to detect if a spatial node is attached to a node that has an animated property binding?

Flags: needinfo?(gwatson) → needinfo?(jnicol)

Yeah I think that does sound reasonable, in fact I thought we already did that: https://searchfox.org/mozilla-central/rev/5359952d8b0be3e706e8c943c2bef2674723b8a9/layout/painting/nsDisplayList.cpp#8086

It would be interesting to know if that flag is being set. If it is not, then why not? And if it is, then why is it not resulting in a local raster space?

Flags: needinfo?(jnicol)
Flags: needinfo?(lsalzman) → needinfo?(gwatson)
No longer blocks: gfx-triage
Severity: -- → S3

I investigated this a bit, and it's definitely that glyphs are being re-rasterized. However, even when I change the code to reuse the quantizing logic applied when pinch-zoom is active, lots of glyphs are still being rasterized.

I need to investigate further - it looks like the quantizing breaks something to do with the caching logic in update_font_instance.

Assignee: nobody → gwatson
Flags: needinfo?(gwatson)

Will this be addressed by bug 1719238 ?

No, that patch only handles when a pinch-zoom is active. However, the fix for this will be somewhat similar.

You need to log in before you can comment on or make changes to this bug.