[Chester Liu (skyline75489)]

This PR Introduces DxFontInfo to simplify the logic in
DxFontRenderData.

DxFontInfo aims to be the DWrite equivalent of FontInfo &
FontInfoBase in GDI. It encapsulates the needed information to
represent a displayable font face. It also provides the ability to
resolve a font face based on the available fonts on the system.

References

This is a follow-up of #9096.
Initial Italic support was introduced by #8580.

The motivation behind this is to support bold & bold-italic text in
Windows Terminal.

[Chester Liu (skyline75489)]

I'm not sure whether this should be familyName or faceName. Seems to me there are familyName & faceName in the GDI font info, but only familyName in DWrite?

[Michael Niksa (miniksa)]

There are face names on the IDWriteFont::GetFaceNames method... the problem tends to be that there are multiple of them depending on the locale or language or variations and GDI just sort of glosses over that. I think we should just continue to focus on the family name until proven otherwise.

[Michael Niksa (miniksa)]

There are face names on the IDWriteFont::GetFaceNames method... the problem tends to be that there are multiple of them depending on the locale or language or variations and GDI just sort of glosses over that. I think we should just continue to focus on the family name until proven otherwise.

[Chester Liu (skyline75489)]

Huh...the trick [skip ci] does not seem to work with Azure Pipelines.

See microsoft/azure-pipelines-agent#1270 (comment) . I don't honestly know what she meant by saying "Azure DevOps honors the [skip ci] commands on CI builds as the change being built has already been merged"

[PankajBhojwani]

Some of the unit tests seem to be failing, other than that this looks good to me!

[Chester Liu (skyline75489)]

OK I have no idea how & why there tests has anything to do with my code:

2021-06-11T16:59:23.2143730Z Summary of Non-passing Tests:
2021-06-11T16:59:23.2144447Z     ControlUnitTests::ControlCoreTests::TestInitialize [Failed]
2021-06-11T16:59:23.2145027Z     ControlUnitTests::ControlCoreTests::TestAdjustAcrylic [Failed]
2021-06-11T16:59:23.2145574Z     ControlUnitTests::ControlInteractivityTests::TestScrollWithMouse [Failed]
2021-06-11T16:59:23.2146125Z     ControlUnitTests::ControlInteractivityTests::CreateSubsequentSelectionWithDragging [Failed]
2021-06-11T16:59:23.2146693Z     ControlUnitTests::ControlInteractivityTests::ScrollWithSelection [Failed]
2021-06-11T16:59:23.2147256Z     ControlUnitTests::ControlInteractivityTests::TestScrollWithTrackpad [Failed]
2021-06-11T16:59:23.2147786Z     ControlUnitTests::ControlInteractivityTests::TestQuickDragOnSelect [Failed]

[Michael Niksa (miniksa)]

OK I have no idea how & why there tests has anything to do with my code:

2021-06-11T16:59:23.2143730Z Summary of Non-passing Tests:
2021-06-11T16:59:23.2144447Z     ControlUnitTests::ControlCoreTests::TestInitialize [Failed]
2021-06-11T16:59:23.2145027Z     ControlUnitTests::ControlCoreTests::TestAdjustAcrylic [Failed]
2021-06-11T16:59:23.2145574Z     ControlUnitTests::ControlInteractivityTests::TestScrollWithMouse [Failed]
2021-06-11T16:59:23.2146125Z     ControlUnitTests::ControlInteractivityTests::CreateSubsequentSelectionWithDragging [Failed]
2021-06-11T16:59:23.2146693Z     ControlUnitTests::ControlInteractivityTests::ScrollWithSelection [Failed]
2021-06-11T16:59:23.2147256Z     ControlUnitTests::ControlInteractivityTests::TestScrollWithTrackpad [Failed]
2021-06-11T16:59:23.2147786Z     ControlUnitTests::ControlInteractivityTests::TestQuickDragOnSelect [Failed]

The failed tests all look like

2021-06-15T11:27:11.3398459Z TAEF: A crash with exception code 0xC0000094 occurred in module "Control.Unit.Tests.dll" in process "te.processhost.exe" (pid:6860).

Where 0xC0000094 is a thrown divide by zero exception. So I'm guessing something about the setup part of those tests is initializing something that is now having a divide by zero with your change. :(

[Paul "TBBle" Hampson (TBBle)]

The common thing in the unit tests looks like a call to ControlCore::Initialize, which calls ControlCore::_updateFont and hence Renderer::TriggerFontChange, which leads to DxEngine::UpdateFont, and hence DxFontRenderData::UpdateFont. This calls DxFontRenderData::_BuildFontRenderData, which is introduced in this patch.

DxFontRenderData::_BuildFontRenderData has lots of division calls in it as well, although at least some of them were already in the code-base, so this might be a red herring.

So at a guess, there's some code-path where some initialisation never happens and hence some value is 0.f. It's being hit by the unit tests' very minimal initialisation, that you aren't seeing in actual testing when you run WT.

[Chester Liu (skyline75489)]

wow thanks Paul "TBBle" Hampson (@TBBle) for the investigation. I'll get to this PR later and found out why. I promise.

[PankajBhojwani]

Thanks!

[Dustin L. Howett (DHowett)]

blocking while reviewing since this has 2 s/o

[Dustin L. Howett (DHowett)]

My personal preference is that we properly extend std::hash; it means that we can use the STL containers with less customization, and perhaps that leads to a higher likelihood that they will be deduplicated as "identical code" 😄

[Deleted user (ghost)]

Hello Dustin L. Howett (@DHowett)!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

[Deleted user (ghost)]

🎉Windows Terminal Preview v1.10.1933.0 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes
• Store Download