Page having runes is brutally slow
Reported by
kenorb@gmail.com,
Jul 12 2016
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 Example URL: https://gist.github.com/huw/8a564d1e8027294df15d Steps to reproduce the problem: 1. Go to: https://gist.github.com/huw/8a564d1e8027294df15d What is the expected behavior? Page should load and work the same as other. What went wrong? Page is very slow, sometimes unresponsive. When it's loading, it's rendered half way through. The same in incognito mode. Does it occur on multiple sites: No Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? N/A Chrome version: 51.0.2704.103 Channel: n/a OS Version: OS X 10.11.2 Flash Version: Shockwave Flash 22.0 r0 I believe this is because of the special characters. They're normally rendered on the other sites such as http://puzzling.stackexchange.com/q/37444/1854, but it seems they've the problem rendering on gist.
,
Jul 12 2016
,
Jul 14 2016
,
Jul 18 2016
An unfortunate case of a large font stack, consisting of 5 fonts: Consolas, "Liberation Mono", Menlo, Courier, monospace; plus OS X' fallback API not returning a font other than "Last Resort" for runic characters. There are also no spaces between the runic words. All combined, this makes shaping very slow. This could be improved: * by introducing a level of manual fallback tweaking on Mac, similar to what we have on Windows? * if not finding a font at all, by having a cache for characters for which no fallback font was found in order to avoid the expensive system call. I've also tried adding fallback code similar to FF' using CTFontCreateForString instead of our NSFont findFontLike approach, but we also only get "LastResort" from that call.
,
Aug 20 2016
I'm seeing similar behavior on the following page, but with emojis: http://apps.timwhitlock.info/emoji/tables/unicode Could it be the same issue? I don't see either of these issues on another machine, though, so it might be hardware/driver specific.
,
Aug 20 2016
I'm on Windows 10, btw, and see the issue.
,
Sep 26 2016
Dropping Blink>TextEncoding label since this is just font-related (unless I'm misunderstanding)
,
Sep 27 2016
I can no longer reproduce the "unresponsive" error in Canary 55.0.2868.0 on either https://gist.github.com/huw/8a564d1e8027294df15d http://apps.timwhitlock.info/emoji/tables/unicode though first paint isn't very fast and scroll a bit sluggish. Stable 53.0.2785.116 is much slower than Canary but not as slow as "unresponsive" error. Can anyone still see the slowness in Canary?
,
Sep 27 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 28 2017
This is now quite a bit faster but still rather slow. LayoutNG will make it significantly faster still, on par with other complex script. No other improvements are planned until then. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by shrike@chromium.org
, Jul 12 2016Status: Untriaged (was: Unconfirmed)
159 KB
159 KB View Download