Lots of jank while trying to re-order links on linktr.ee
Categories
(Core :: Layout: Text and Fonts, 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:
- Access https://linktr.ee/admin
- Log in with a test account, or create a test account
- 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•2 years ago
|
||
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•2 years ago
|
||
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.
Updated•2 years ago
|
![]() |
||
Updated•2 years ago
|
![]() |
||
Updated•2 years ago
|
Description
•