Make native-font-resource-mac memory report match format of user-fonts report
Categories
(Core :: Graphics, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox84 | --- | fixed |
People
(Reporter: bradwerth, Assigned: bradwerth)
References
Details
Attachments
(1 file)
The user-fonts report includes url of the loading page, and has a different text format. The reporter for native-font-resource-mac should match this format, and include the loading url (when not anonymized).
Assignee | ||
Comment 1•5 years ago
|
||
Hmm... unless I'm missing something, it looks pretty challenging to get loading url information down to the main process memory reporter. A solution might look like...
- The last time we have access to the document on the content process side appears to be at gfxFont::Draw, where we could get the document by climbing up from aTextRun -> mUserData -> AsContent() -> mDocument.
- From that point we could copy the document url into the GlyphBufferAzure::mRunParams or ::mFontParams.
- In GlyphBufferAzure::FlushGlyphs, add the document url into the call to the recorder somehow.
- Make DrawTargetRecording::FillGlyphs record the url in the RecordedFontData.
- Unpack it in the main process and store the document url alongside the font data and font name.
So I think it could be done. Is it worth doing? I'd like feedback from Henrik, who initially noted this issue.
Comment 2•5 years ago
|
||
When investigating memory leak / usage it would definitely help to know which website actually triggered the loading of the font. But given that we won't cache the native fonts anymore once bug 1625590 landed, the memory usage here should be small, right? That said it might be indeed not worth the time doing that change, also because it sounds complicated.
Comment 3•5 years ago
|
||
IMO, it's not worth trying to do this. It'd add significant overhead to the text drawing code, which can be pretty "hot" in terms of performance, for very little benefit given that we're fixing the underlying issue whereby installed fonts are passed around/cached in their entirety instead of by reference.
(For webfonts, the font resource is inherently linked to the site that loaded it; a given webfont is not available globally but is attached to a document. So in that case we can readily report what document the font belongs to. But installed fonts don't have such an association; they're a global resource.)
Assignee | ||
Comment 4•5 years ago
|
||
I can still land something to make the reporting template match what we do for user-fonts, minus the url reporting. I'll post a patch and seek review.
Assignee | ||
Comment 5•5 years ago
|
||
We don't cache the url, but we do report the "family=" preface, and we respect
the anonymizer flag in the same way that user-fonts are reported.
Comment 7•5 years ago
|
||
bugherder |
Description
•