1875278 - (with gfx shared font) Stating browser by opening a emoji-filled HTML file does 4s of work on parent process, file process and sync IPC on webextension process

Status: RESOLVED FIXED

(Core :: Graphics: Text, enhancement)

Description

[Mayank Bansal]

This is more of an exploratory/curiousity bug.
STR:

1. Download the attached html file to your local machine
2. Close the browser completely
3. Double click on the html file such that the browser will start with the html file

AR: Tons of work done on parent process, file process and sync IPC on webextension (ublock)
ER: Maybe something to improve?

Ignore the actual painting work in rendering the emojis.

Profiles captured by double-clicking on the file, and then starting the profiler when the UI is generated and the profiler icon is visible:
Opening the browser by clicking on html file : https://share.firefox.dev/3vEdquf / https://share.firefox.dev/47OmpXa
File opened after the browser has been open : https://share.firefox.dev/48JEEhK

Comment 1

[Mayank Bansal]

Attachment: about:support

Comment 2

[Mayank Bansal]

Attachment: emoji_working.html

Comment 3

[Mayank Bansal]

Here are profiles where I do "startup profiling" by setting environment variables:

startup with html file: https://share.firefox.dev/3Soby1p
Normal startup: https://share.firefox.dev/3vMAYwK

Comment 4

[Mayank Bansal]

This appears to be related to the gfx shared font thingy.

Manually triggering profiler ASAP after opening the file:
no shared font: https://share.firefox.dev/3HsCCq7 / https://share.firefox.dev/3HrBoeQ
shared font: https://share.firefox.dev/47KrRKy / https://share.firefox.dev/429aXnq

With startup profiling:
no shared font: https://share.firefox.dev/3O783tR
shared font: https://share.firefox.dev/4289RbH

Comment 5

[Mayank Bansal]

I also dont know why there is such a big difference in profiles between manually starting profiling Vs "startup profiling"

Comment 6

[Markus Stange [:mstange]]

(In reply to Mayank Bansal from comment #4)

This appears to be related to the gfx shared font thingy.

Manually triggering profiler ASAP after opening the file:
no shared font: https://share.firefox.dev/3HsCCq7 / https://share.firefox.dev/3HrBoeQ
shared font: https://share.firefox.dev/47KrRKy / https://share.firefox.dev/429aXnq

The second shared font profile here has 332446 StartCmapLoading messages in it (https://share.firefox.dev/3Uciksu). That seems a bit much!

Comment 7

[Jonathan Kew [:jfkthame]]

Ugh, yeah - that's bad. I guess each time we hit one of the emoji characters and need to do font fallback, this happens because the charmaps have not yet been loaded. The loading process will have been started the first time it happens, but hasn't yet completed, and so font fallback keeps asking for it.

The parent process will basically discard the extra requests (unless they cover more of the font collection, but in this case it'll be the same every time), but we should try to avoid sending them at all because all that ipc traffic is hurting.

I'll look into what we can do to mitigate this.

Comment 8

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1875278 - Avoid repeatedly sending StartCmapLoading message for the same font-family index. r=#gfx-reviewers

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2276ab3d4000
Avoid repeatedly sending StartCmapLoading message for the same font-family index. r=gfx-reviewers,lsalzman

Comment 10

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/2276ab3d4000

Comment 11

[Mayank Bansal]

A try build worked great (there was only 1 startcmap msg).
But i will do a better test.

Comment 12

[Mayank Bansal]

manual profiling: https://share.firefox.dev/3OiNGtO
startup profiling: https://share.firefox.dev/3SAlEME

Id say this is fixed.

Comment 13

[Jonathan Kew [:jfkthame]]

Thanks for reporting it, and for confirming the fix.