1493353 - Loading page full of emojis makes the throbber animation janky

Status: VERIFIED FIXED

(Core :: Graphics: WebRender, defect, P3)

Description

[Mayank Bansal]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0
Build ID: 20180921220134

Steps to reproduce:

enable WR
open https://bug1479196.bmoattachments.org/attachment.cgi?id=8995725



Actual results:

while the page loads, the page-loading-throbber janks


Expected results:

not so

Comment 1

[Jeff Muizelaar [:jrmuizel]]

Can you get a profile of this?

Comment 2

[Mayank Bansal]

http://bit.ly/2IqF4y2

I loaded the page twice. So the two regions of red janks in the profile relate to the the page being loaded twice.

Comment 3

[Mayank Bansal]

I noticed the previous profile had some restyle stuff. So i took a new profile with "Sequential Styling" added in the profiler. This limits Stylo to use only one thread. This should minimize any CPU starvation due to stylo:


http://bit.ly/2xIPi8Q

Comment 4

[Jeff Muizelaar [:jrmuizel]]

What hardware is this on?

Comment 5

[Mayank Bansal]

Attachment: aboutsupport.txt

Comment 6

[Mayank Bansal]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #4)
> What hardware is this on?


mobile broadwell Corei3-5010U (2C/4T) + iGFX HD5500 +8GB RAM+SSD+ Win10x64

Comment 7

[Mayank Bansal]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #4)
> What hardware is this on?

Also forgot to mention, I upgraded windows to the October update, and the attachment of emojis doesnt render correctly for me anymore. All I get are boxes, and huge memory use. Chrome renders it OK.
Meant to file a bug, but forgot

Comment 8

[Mayank Bansal]

(In reply to Mayank Bansal from comment #7)
> Also forgot to mention, I upgraded windows to the October update, and the
> attachment of emojis doesnt render correctly for me anymore. All I get are
> boxes, and huge memory use. Chrome renders it OK.
> Meant to file a bug, but forgot

filed bug 1499451

Comment 9

[Glenn Watson [:gw]]

This ends up with ~800k primitives - I suspect that Gecko is breaking each glyph into a separate text run?

Additionally - WR thinks every one of those primitives is visible. One possible explanation of this is that Gecko may be supplying an oversized bounding rect for the glyphs?

Comment 10

[Mayank Bansal]

Attachment: emoji_working.html

FWIW, this page has emojis that will actually display as emojis on screen, and not weird tofu boxes. This also janks the throbber, but the total page load time is much faster than I remember. So might be slightly difficult to repro.

Comment 11

[Matt Woodrow (:mattwoodrow)]

I have a patch that brings the prim count down to just over 300.

The majority of the primitives were for the missing glyph characters, so I've added code to cull ones outside of the visible region from the display list.

There's still all the normal glyphs in a single text run, which causes the backend to take 40ms, but every other phase is basically instant, so we can scroll at ~20fps (and 3-4fps without the patch).

Display list/scene building time is way down, so it checkerboards much less.

We could probably do better by culling the actual glyphs to what is visible (either during DL building, or somewhere within WR), but I can't find performant gecko code to do it, and I don't think this blocks the MVP with the patch applied.

Comment 12

[Matt Woodrow (:mattwoodrow)]

Attachment: Bug 1493353 - Clip TextDrawTarget to the visible rect, and avoid emitting display items that are outside the clipped area. r?jrmuizel

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d8a944c012a7
Clip TextDrawTarget to the visible rect, and avoid emitting display items that are outside the clipped area. r=jrmuizel

Comment 14

[Cosmin Sabou [:CosminS]]

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

Comment 15

[Mayank Bansal]

Matt, which testcase did you take for this bug ?

https://bug1479196.bmoattachments.org/attachment.cgi?id=8995725  is AFAIK an ANSI coded emoji page, which shows as tofu boxes on my system. That page no longer causes high heap-unclassified memory use (bug 1511354)  loads almost instantly(probably this bug), and scrolls horizontally pretty well.

Did you also test with https://bugzilla.mozilla.org/attachment.cgi?id=9030975 ? This is a UTF coded emoji page, which displays actual emojis in a big grid. That page still scrolls not so good ( bug 1479201). This is mostly an artificially terrible page, but scrolls pretty well with checkerboarding on non-WR.

Comment 16

[Matt Woodrow (:mattwoodrow)]

(In reply to Mayank Bansal from comment #15)
> Matt, which testcase did you take for this bug ?
> 
> https://bug1479196.bmoattachments.org/attachment.cgi?id=8995725  is AFAIK an
> ANSI coded emoji page, which shows as tofu boxes on my system. That page no
> longer causes high heap-unclassified memory use (bug 1511354)  loads almost
> instantly(probably this bug), and scrolls horizontally pretty well.
> 
> Did you also test with
> https://bugzilla.mozilla.org/attachment.cgi?id=9030975 ? This is a UTF coded
> emoji page, which displays actual emojis in a big grid. That page still
> scrolls not so good ( bug 1479201). This is mostly an artificially terrible
> page, but scrolls pretty well with checkerboarding on non-WR.

I just tested the former, and the fixes were mainly to do with reducing work for glyphs that aren't actually on screen.

Comment 17

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

I reproduced this issue using Fx 64.0a1 (2018-09-21), on Windows 10 x64.
I can confirm this issue is fixed, I verified using Fx 66.0b13, on macOS 10.13, Windows 10 x64 and Ubuntu 16.04 LTS.