msw@chromium.org is the owner listed in ui/gfx/OWNERS for RenderText, as well as for ui/views/

I'm not actively working on RenderText, so I'm not the best owner here.
Some performance might be gained by refining TaskManager/TableView/TaskManagerTableModel, etc.
I'm CC'ing c/b/ui/task_manager/OWNERS, but Windows Desktop UI folks should probably triage this.
(I suppose available/pri-3 is ok, if it's really only janky with --enable-heap-profiling=native)

sky@ Do you know who works on RenderTextHarfBuzz:EnsureLayoutRunList?

No idea. I recommend looking at who has been submitting patches to it.

+cburn, FYI

My recollection is that ahmed had encountered a variant of this, and fixed it by means of the TaskManagerValuesStringifier in the TaskManagerTableModel. That always seemed a bit of a weird band-aid to me, but the perf gains were demonstrably real; if we need a text cache, it seemed like it ought to exist at a lower layer.

Would love to get to the bottom of this.

asvitkine@ has suggested a global cache of text runs before:
( see http://crbug.com/424082#c69 and http://crbug.com/641726#c29 )
tapted@ did some perf analysis at http://crbug.com/641726#c27
eae@ might have some suggestions based on Blink's text rendering.

If the Jank principally occurs while scrolling, then  Issue 605131  may be relevant. Specifically, r411889 -> https://codereview.chromium.org/2188133002 set up views::ScrollView to scroll using a Layer on Mac because the approach it uses otherwise was too slow for the rate of trackpad events Mac generates.

E.g. does the jank go away if you run with

--enable-features=ToolkitViewsScrollWithLayers

?

(There is a downside currently, in that horizontal scrolling in the header row can be a frame ahead of the scrolling in the contents, since the header row still paints synchronously. That can be fixed with a fancier layer setup, or possibly ignored since it's fiddly to get the task manager into a situation where it needs to scroll horizontally).

Re #8: This behaviour is observed on Windows, and doesn't involve scrolling the Task Manager view - the 0.5s jank is when (1) malloc is slow, due to heap-profiling and (2) Task Manager refreshes.

Ideally Task Manager should being careful to re-use string buffers, and to only re-render things to strings if they've changed (so a mixture of buffer re-use and caching, in effect); we have some string caching but I think we can do a better job at buffer re-use and only.

yep - ToolkitViewsScrollWithLayers happens by default on Mac, but Windows could benefit too (just, when I've tested there, it doesn't seem to impact things much because mouse events come in so slow).

I think to fix, a big impact would be for us to cache gfx::RenderText instances in ui::TableModel (or something with that effect). Then TableView::OnPaint can stop using Canvas::DrawStringRectWithFlags(..), which creates a new gfx::RenderText instance each time.

Caching text runs would help at a lower level, but it's a lot more complicated / more work (and DrawStringRectWithFlags still does a lot of work that wouldn't be cut out).

Oh yeah, if you're not caching RenderText instances (or similar via views::Label), then you're doing layout and shaping on every paint pass. Seems like TableView should cache RenderText instances.

It looks like there's some ideas for fixing in comments 10 and 11. Who should own/do this work? I'm also wondering if this is related to Issue# 737304