Was this already addressed by http://crrev.com/2791043002 and in particular https://codereview.chromium.org/2791043002/patch/170001/180008 ?

It looks like the one callsite to WebFont::drawText in content/child/browser_font_resource_trusted.cc a.k.a. BrowserFontResource_Trusted::DrawTextToCanvas passes null for the GraphicsContext and PaintController, and so the PaintRecorder will actually instantiate a new instance for every drawText call, which is unfortunate because in fact we call WebFont::drawText in a loop over each text run here:

https://cs.chromium.org/chromium/src/content/child/browser_font_resource_trusted.cc?gsn=DrawText&l=439

and I think we could theoretically factor this so that we reuse the same context/controller, or even perhaps so that we don't need them at all, which was IIUC sort of the original point of this bug.

I couldn't quickly find layout tests that fail if I remove all logic in WebFont::drawText. It looks like the callsite tracing from BrowserFontResource_Trusted::DrawTextToCanvas is through PPAPI. Maybe that's just an artifact of how Canvas is implemented, I haven't looked at it closely to date. But I do see some tests under fast/canvas that use drawText.

Anyway, thought best to solicit more input before doing anything else here.

Not sure what you mean about the context/controller. The callsite uses an
SkCanvas, which could be drawn directly to.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot