-
-
Notifications
You must be signed in to change notification settings - Fork 170
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Performance issue in font.c #509
Comments
P.S. |
You know I thought about this while implementing bcfnt but the format doesn't guarantee that the glyphs are sorted. Can we assume that they are always sorted? Output from bcfnt will be. We could easily check all the official system fonts. Do we care about fonts from anywhere else? |
I think we should only care about official system fonts + fonts created by our own mkbcfnt tool. |
Theoretically I could see an argument for caring about game fonts but I find it unlikely that they won't match system fonts; the conversion tool used is very likely the same |
A PR would be very much appreciated if you're still interested in pursuing this. |
The function
fontGlyphIndexFromCodePoint
is called for every character when drawing text with citro2d, for example.The system font seems to handle characters using three mappings: CMAP_TYPE_DIRECT, CMAP_TYPE_TABLE, CMAP_TYPE_SCAN
The first two are fine, but for CMAP_TYPE_SCAN libctru currently does a linear search, which may be slow.
It seems that the codepoints of the characters in one CMAP_TYPE_SCAN cmap are monotonically increasing, so we can do a binary search to significantly reduce running time.
In fact, on my JPN 3ds, the mapping of the default font includes one cmap of type CMAP_TYPE_SCAN with 5811 characters in it.
I test on a new 3ds with "龍" (Dragon) which is one of the standard Japanese characters with a large codepoint, and it was only 15k calls/s. This means we can only draw 250 characters if it's 60FPS.
On my test implementation of the binary search, it marked 500k calls/s: 8000 characters/frame
I am curious if you would accept a PR if I did.
Here is my test implementation to see how simple it would be:
Test implementation
Before:
After:
The text was updated successfully, but these errors were encountered: