mirror of
https://github.com/ultimatepp/ultimatepp.git
synced 2026-05-15 14:16:07 -06:00
[GH-ISSUE #79] UTF-8 illegal and overlong sequences cause U++ apps to block UI for very long time. #48
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/ultimatepp#48
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ismail-yilmaz on GitHub (Jul 4, 2022).
Original GitHub issue: https://github.com/ultimatepp/ultimatepp/issues/79
Tested on: Linux/GNOME 42/Wayland (Xwayland)
How to reproduce (always reproducible):
Note: This happens on all U++ based apps. Happens only once (Possibly a glyph rendering/caching problem?)
@ismail-yilmaz commented on GitHub (Feb 25, 2024):
A similar issue with cjk and characters with no glyphs. Try opening the below file in theide. TheIDE will hang for several seconds, depending on the machine. This "feels" like a rendering/caching issue.
cjk.txt
@mirek-fidler commented on GitHub (Feb 28, 2024):
Both examples work for me, tested win32&Ubuntu.
That said, the most likely cause is that font replacement for some reason
works slowly. For starters, you can try with
return false;
at the start of Replace function at Draw/FontCR.cpp:350
Mirek
On Sun, Feb 25, 2024 at 7:17 PM İsmail Yılmaz @.***>
wrote:
@ismail-yilmaz commented on GitHub (Feb 29, 2024):
Yes, it appears to be the Replace function: Here is a log and timing:
Timings:
Reported substitutions
@ismail-yilmaz commented on GitHub (Feb 29, 2024):
I don't see anthing odd with these timings.
At least, now I know where to look at.
I'll try to play with the code and see if I can spot anything unusual, thanks.
@mirek-fidler commented on GitHub (Feb 29, 2024):
One idea is to preload cmap info in background thread on app start... worth
it?
On Thu, Feb 29, 2024 at 4:27 PM İsmail Yılmaz @.***>
wrote:
@mirek-fidler commented on GitHub (Mar 5, 2024):
Well, I was not sure whether the last post was just accidental, now after
parsing it, it seems like the problem is in "downsizing" the font to fit
ascent / descent, right?
If that is the case, maybe benchmarking ascent method and deeper?
Mirek
On Thu, Feb 29, 2024 at 4:27 PM İsmail Yılmaz @.***>
wrote:
@mirek-fidler commented on GitHub (Mar 5, 2024):
What specific distro is this?
On Tue, Mar 5, 2024 at 9:26 AM Mirek Fidler @.***> wrote:
@ismail-yilmaz commented on GitHub (Mar 5, 2024):
ArchLinux
@mirek-fidler commented on GitHub (Mar 5, 2024):
Ah. So I guess some font is too "slow" in FT. Maybe you could use TIMESTOP
and some LOGs in GetGlyphInfo to find out what font has the problem?
Also, maybe we could use cmaps directly, that would fix it as well I think.
On Tue, Mar 5, 2024 at 5:04 PM İsmail Yılmaz @.***>
wrote:
@ismail-yilmaz commented on GitHub (Mar 6, 2024):
The log below represents the max time spent for fonts in
GetGlyphInfoSys(Used TimeStop instead):P.s Edit.
@mirek-fidler commented on GitHub (Mar 6, 2024):
So it looks like FT has some problems with
Font: ---- timing: 5378
?
On Wed, Mar 6, 2024 at 6:13 AM İsmail Yılmaz @.***>
wrote:
@ismail-yilmaz commented on GitHub (Jul 22, 2025):
@mirek-fidler
The commit
e0fdb0c-and value cache improvements I guess- seems to finally fixed this issue. And it not only fixed it, the unicode codeblocks are now displayed in a very fast manner. (I've benchmarked it with notcurses' uniblock rendering benchmark on TerminalCtrl/Bobcat and on several other "performant" terminals, and rendering is on par with them. Thanks!Closing this issue.