1727851 - High cpu usage rendering mixed-width strings within an x-scrollable element with border-{top,bottom}-{left,right}-radius

Status: NEW

(Core :: Graphics: Text, defect)

Description

[Paul Vitale [:iidebyo]]

Attachment: example.html

Rendering mixed-width strings within an x-scrollable element and at least one css rule: border-bottom-left-radius, border-bottom-right-radius, border-top-right-radius, or border-top-left-radius is slow.

Only occurring on macOS. FF91 and Nightly.

Disabling hardware acceleration fixes this for me.

An example page is attached. If you change 'data' to '111', '漢字漢字' or another homogeneous-width string, there's no issue (at least not yet).

profiling from slow render: https://share.firefox.dev/3BfAexF

Steps to reproduce

1a. Visit https://github.com/jregistr/rtk-companion/blob/master/src/support_files/kanji_data.json (this one has caused my computer to restart before)
1b. OR Load the html attached
2. Try scrolling the text field
3. Observe cpu usage and slow scroll

Actual results

Rendering is slow compared to other strings.

Expected results

Rendering should be as fast as with any other string of a similar length.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:lsalzman, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 2

[Lee Salzman [:lsalzman]]

It seems like we're spending a relatively large amount of time inside the Mac GL implementation's DrawElements, but I'm not really sure what would be causing this upwind in WR. I'm not sure this is a text bug, and maybe more of a batching issue if I had to guess?

Comment 3

[Nicolas Silva [:nical]]

3k draw calls scrolling the provided test case (explains the time spent in DrawElements). The frame builder thread is also spending most of its time in the batching logic.