Skip to content
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

Consider performing font fallback analysis only if the chosen font is not adequate #10858

Open
skyline75489 opened this issue Aug 3, 2021 · 2 comments
Labels
Area-Performance Performance-related issue Area-Rendering Text rendering, emoji, complex glyph & font-fallback issues Issue-Task It's a feature request, but it doesn't really need a major design. Product-Terminal The new Windows Terminal.
Milestone

Comments

@skyline75489
Copy link
Collaborator

Description of the new feature/enhancement

Right now the _AnalyzeFontFallback is always called if the text is "complex":

// Perform our custom font fallback analyzer that mimics the pattern of the real analyzers.
RETURN_IF_FAILED(_AnalyzeFontFallback(this, 0, textLength));

We already know that even for pure ASCII characters, some fonts will treat them as "complex". But the real need for font fallback emerges only when the font don't actually contains the needed glyph. For example when dealing with "ABC中文". You have to find "Microsoft YaHei" as fallback, otherwise "中文" is nowhere to be find in "Cascadia Code“.

Proposed technical implementation details (optional)

To avoid the unnecessary overhead of finding fallbacks (MapCharacters, which is relatively expensive), my proposed solution is to delay the fallback analysis and put it in _ShapeGlyphRun. Inside _ShapeGlyphRun, the method GetGlyphs will tell you precisely if there are available glyphs inside the desired font (_glyphIndices):

hr = _fontRenderData->Analyzer()->GetGlyphs(

If no glyphs can be found (which I assume is a rather rare case), then the fallback analysis is necessary.

@skyline75489 skyline75489 added the Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. label Aug 3, 2021
@ghost ghost added Needs-Tag-Fix Doesn't match tag requirements Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Aug 3, 2021
@skyline75489
Copy link
Collaborator Author

/cc @miniksa

@zadjii-msft
Copy link
Member

That makes sense to me

@zadjii-msft zadjii-msft added Area-Performance Performance-related issue Area-Rendering Text rendering, emoji, complex glyph & font-fallback issues Issue-Task It's a feature request, but it doesn't really need a major design. Product-Terminal The new Windows Terminal. and removed Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. labels Aug 3, 2021
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Aug 3, 2021
@zadjii-msft zadjii-msft added this to the Terminal Backlog milestone Aug 3, 2021
@zadjii-msft zadjii-msft removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Aug 5, 2021
@zadjii-msft zadjii-msft modified the milestones: Terminal v2.0, 22H2 Jan 4, 2022
@zadjii-msft zadjii-msft modified the milestones: 22H2, Backlog Jul 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Performance Performance-related issue Area-Rendering Text rendering, emoji, complex glyph & font-fallback issues Issue-Task It's a feature request, but it doesn't really need a major design. Product-Terminal The new Windows Terminal.
Projects
None yet
Development

No branches or pull requests

2 participants