Loading page full of emojis makes the throbber animation janky

VERIFIED FIXED in Firefox 66

Status

()

defect
P3
normal
VERIFIED FIXED
9 months ago
4 months ago

People

(Reporter: mayankleoboy1, Assigned: mattwoodrow)

Tracking

(Blocks 2 bugs, {regression})

Trunk
mozilla66
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox64 wontfix, firefox65 wontfix, firefox66 verified)

Details

Attachments

(3 attachments)

Reporter

Description

9 months ago
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
Reporter

Updated

9 months ago
See Also: → 1490563
Reporter

Updated

9 months ago
Summary: Loading page full of emojis makes the throbber janky → Loading page full of emojis makes the throbber animation janky
Priority: -- → P2
Priority: P2 → P3
Can you get a profile of this?
Flags: needinfo?(mayankleoboy1)
Reporter

Comment 2

9 months ago
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.
Flags: needinfo?(mayankleoboy1) → needinfo?(jmuizelaar)
Reporter

Comment 3

9 months ago
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
What hardware is this on?
Flags: needinfo?(mayankleoboy1)
Reporter

Comment 5

8 months ago
Posted file aboutsupport.txt
Flags: needinfo?(mayankleoboy1)
Reporter

Comment 6

8 months ago
(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
Reporter

Comment 7

8 months ago
(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
Reporter

Comment 8

8 months ago
(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
See Also: → 1499451

Comment 9

7 months ago
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?
Assignee

Updated

7 months ago
Assignee: nobody → matt.woodrow
Flags: needinfo?(jmuizelaar)
Reporter

Comment 10

7 months ago
Posted file 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.
Assignee

Comment 11

7 months ago
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 13

6 months ago
Pushed by mwoodrow@mozilla.com:
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

6 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/d8a944c012a7
Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
Reporter

Updated

6 months ago
Blocks: 1479201
Reporter

Comment 15

6 months ago
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.
Flags: needinfo?(matt.woodrow)
Assignee

Comment 16

6 months ago
(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.
Flags: needinfo?(matt.woodrow)
Flags: qe-verify+
Whiteboard: [qa-triaged]
QA Whiteboard: [qa-triaged]
Whiteboard: [qa-triaged]

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.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.