1709072 - Lots of jank while trying to re-order links on linktr.ee

Status: NEW

(Core :: Layout: Text and Fonts, defect)

Description

[Dennis Schubert [:denschub]]

This was initially reported as a webcompat issue. I'm filing this in Core::Performance, hoping that someone with a bit more experience can help us identify where the issue actually is.

Basic information

Steps to Reproduce:

1. Access https://linktr.ee/admin
2. Log in with a test account, or create a test account
3. Add some links, then try drag-and-droppnig the links around to reorder them.

Expected Results:

Smooth reorder-action.

Actual Results:

A hard time getting the dragging started in the first place because the UI is a bit unresponsive, and then super janky motion.

---

More information

Screenshot: (if relevant, please attach a screenshot or screencast to this bug report)

Profile URL: (follow the instructions at https://profiler.firefox.com/) https://share.firefox.dev/3aZDtPb

Basic systems configuration:

OS version: Android 11

GPU model: Don't actually know; whatever is in the moto g7 power.

Number of cores: See above.

Amount of memory (RAM): See above.

Thanks so much for your help.

Comment 1

[Bas Schouten (:bas.schouten)]

We seem to be spending a considerable amount of time (30%+) in TT_RunIns. It's quite possible we should be able to reuse something here, this function is TrueType related, changing the component.

Jonathan, any ideas here?

Comment 2

[Jonathan Kew [:jfkthame]]

The stack in that profile doesn't seem very helpful.... TT_RunIns would be FreeType processing instructions ("hints") in a TrueType font, but it's not clear what the real call-stack is like (I would think there must be a bunch of other Gecko and FreeType code in between the site's JS and the eventual time spent in TT_RunIns but we don't seem to have correct stack frames for it).

Given the lack of a clear Gecko call-stack, I'm guessing here but I wonder if the site is doing something that defeats our attempts to cache fonts or text runs, so that we're constantly re-measuring the same bits of text while the interaction is going on.

Hmm - one thing might be if they're redrawing text to a canvas2d context, as IIRC we don't cache a textrun for that, it's just rendered on the fly. But even so, we should have cached glyph widths and bitmaps such that redrawing the same text doesn't involve re-executing all the hinting instructions.

Comment 3

[Calin Tanase]

Attachment: FF vs Chrome.mp4

Seems to be more of a website issue now, If it's janky on Firefox on a phone, it's the same on Chrome. For me it worked fine on Pixel 5 on both Firefox and Chrome but it was janky on my One+ on both browsers.

Tested on:
• Browser / Version: Firefox Nightly 127.0a1-20240415203932 / Chrome 123.0.6312.40
• Operating System: OnePlus 6 A6000 (Android 11) - 1080 x 2280 pixels, 19:9 ratio (~402 ppi pixel density) / Google Pixel 5 (Android 14) - 1080 x 2340 pixels, 19.5:9 ratio (~432 ppi density)