Closed Bug 419744 Opened 15 years ago Closed 15 years ago

load font cmap info via a background task on windows

Categories

(Core :: Graphics, defect, P2)

x86
Windows XP
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: jtd, Assigned: jtd)

References

Details

(Keywords: perf)

Attachments

(1 file, 4 obsolete files)

Follow-on bug from bug 416946 which implements deferred cmap loading on the mac.  Windows current loads all cmaps at startup in InitFontList.  Moving this out of the startup process would improve startup time.
Priority: -- → P3
Depends on: 382542
Keywords: perf
Depends on: 424018
With Stuart's lazy cmap loading work in 424018, doing cmap loading in an idle proc is now more important on Windows.  Bumping to a P2 blocker.
Flags: blocking1.9?
Priority: P3 → P2
Flags: blocking1.9? → blocking1.9+
Attached patch work in progress patch, untested (obsolete) — Splinter Review
This includes the contents of patch v.0.4 for 416946.  Untested, buyer beware!
The underlying timer code exhibits weird behavior when re-init'ed as a recurring timer rather than a one shot, the callback gets called twice in succession.  So I just simplified the code to adjust the interval after the initial delay, this reduces the housekeeping code.

Timer parameters same as on mac, 10sec initial delay then loads occur in 150ms intervals.  Using perf timers it looks like the loads average about 20ms each.

Note: like the last patch, this also includes the mac loading code from bug 416946, patch v.0.4
Attachment #313030 - Attachment is obsolete: true
With this patch, gfxWindowsPlatform and gfxQuartzFontCache both subclass gfxFontInfoLoader.  Because of this, changed the virtual methods to be xxxLoader (e.g. Run ==> RunLoader) to avoid method name collisions.  This simplifies things a bit, removes the need to have an extra object that just hangs around.

Stuart, let me know what you think and I'll set up a patch that removes all the debugging stuff.
Attachment #313244 - Attachment is obsolete: true
Attachment #313286 - Attachment is obsolete: true
Attachment #313300 - Flags: superreview?(pavlov)
Attachment #313300 - Flags: review?(pavlov)
Blocks: 416946
Status: NEW → ASSIGNED
No longer depends on: 416946
Running on my system, measuring the size of the gfxSparseBitSet structures used to store the cmaps per face:

With size += sizeof(nsAutoPtr<Block>) in gfxSparseBitSet::GetSize:
  561 faces, 1100288 bytes (1074KB)
  
Without:
  561 faces, 448864 bytes (438KB)
  
So just the nsAutoPtr's in the set are taking up 636KB.  That's probably why bumping up the block size affects the overall memory usage.

Switch to private gfxFontInfoLoader inheritance, adjust gfxSparseBitSet size calculation.
Attachment #313508 - Flags: superreview?(pavlov)
Attachment #313508 - Flags: review?(pavlov)
Attachment #313300 - Attachment is obsolete: true
Attachment #313300 - Flags: superreview?(pavlov)
Attachment #313300 - Flags: review?(pavlov)
Attachment #313508 - Flags: superreview?(pavlov)
Attachment #313508 - Flags: superreview+
Attachment #313508 - Flags: review?(pavlov)
Attachment #313508 - Flags: review+
checked in.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Depends on: 661969
You need to log in before you can comment on or make changes to this bug.