734308 - optimize cmap-based system font fallback

Status: RESOLVED WONTFIX

(Core :: Graphics, defect, P2)

Description

[John Daggett (:jtd)]

This is a follow-on bug to bug 705594.  The patches landed for that patch implement hard-coded fallback and system-based font fallback where it was possible.  But for WinXP and non-DirectWrite-enabled Windows machines, cmap-based system font fallback is still used.

Optimize this by:

1. Calculating font coverage info, caching that in the startup cache
2. Based on font coverage info, only load full cmaps for fonts with coverage
3. Implement a timeout as part of system fallback, such that fallback fails and a background thread/event thingy completes the work and reflows if needed

The patches for (1) and (2) are attached to bug 705594, I need to write the patch for (3).  The timeout is what will solve the underlying P1 Snappy bug 705258.

Comment 1

[John Daggett (:jtd)]

(In reply to Behdad Esfahbod from bug 705594, comment #86)
> I'm late to this bug, and didn't get all the details.  But did you consider
> using the TrueType coverate bitvector?

I assume you're referring to the OS/2 unicodeRange bits.  I did look at this but opted for a customized list for a couple reasons.  First, we don't want to assume that those are correct.  And in some cases we want to use a finer granularity where there are typically lots of fonts that support a given range sparsely (e.g. the symbol/punctuation ranges in Unicode, u+2xxx).  So the strategy I'm using is to try and limit the ranges to ones that will reduce the number of fonts that need to be tested.

Comment 3

[Vladan Djeric (:vladan)]

Attachment: Hangs in GDIFontEntry::ReadCMAP()

These are top font chrome-hang stacks involving ReadCMAP. I'm not sure if all 3 of these stack signatures are symptoms of the same bug.

Comment 4

[John Daggett (:jtd)]

(In reply to Vladan Djeric (:vladan) from comment #3)
> Created attachment 734895 [details]
> Hangs in GDIFontEntry::ReadCMAP()
> 
> These are top font chrome-hang stacks involving ReadCMAP. I'm not sure if
> all 3 of these stack signatures are symptoms of the same bug.

What's the methodology behind the data here?  Time between event loop spins?  Can you reproduce testcases for any of these or is this based on data from users where we don't know the contents that caused these?

Comment 5

[John Daggett (:jtd)]

One other thing to emphasize here is that this is GDI so it only turns up on WinXP and when hardware acceleration is disabled under Windows 7+.

Comment 6

[Vladan Djeric (:vladan)]

These are user hangs, automatically submitted by Nightly 22.

The hang detector wakes up every 2.5 seconds and checks if the main thread is still working on the same event as last time. If the main thread has not finished the event after 5 seconds, the hang detector captures a snapshot of the current state of the C stack. Eventually, the main thread finishes the long-running event and these hang stacks get reported to Telemetry servers.

Comment 7

[John Daggett (:jtd)]

Since this really only affects GDI usage and the majority of Windows users will be using the DirectWrite backend, marking this as WONTFIX.