Open Bug 1709072 Opened 1 year ago Updated 8 months ago

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

Categories

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

defect

Tracking

()

Webcompat Priority P3

People

(Reporter: denschub, Unassigned)

References

()

Details

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.

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?

Component: Performance → Layout: Text and Fonts
Flags: needinfo?(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.

Flags: needinfo?(jfkthame)
Severity: -- → S3
Webcompat Priority: --- → ?
Webcompat Priority: ? → P3
You need to log in before you can comment on or make changes to this bug.