https://bugs.documentfoundation.org/show_bug.cgi?id=163945
--- Comment #28 from Patrick (volunteer) <[email protected]> --- (In reply to Telesto from comment #26) > Created attachment 197729 [details] > Xcode Instruments Performance trace resizing a column in calc Thank you for the Instruments output. Even though I cannot reproduce this bug, I was trying to use Instruments earlier today to see there were any obvious places in the LibreOffice or Skia code that is using a high percentage of the CPU time. In your output, LibreOffice's slowest stack is in its "draw a native control" code so I tried to turned off automatic spellchecking, hid every toolbar, hid the status bar, and closed the sidebar since those all contain native controls (e.g. buttons, comboboxes, etc.). I then did an Instruments Time Profile while rapidly changing the selected cells using the trackpad since resizing a column in the column header displays tooltips which appear to also draw native controls. After doing the above, I got the Instruments output in attachment #197730. In my output, LibreOffice's slowest stack is in SkiaSalGraphicsImpl::flushSurfaceToWindowContext() (see row 24). This is the function where LibreOffice copies the Skia/Metal offscreen image to the native window. So I expanded that function before I copied it from Instruments (see rows 25 through 36) and it looks like most of time in that function is spent in Skia's GrDirectContext::flushAndSubmit(GrSyncCpu) (see row 25). I would be interested to see if you get similar results as me (and is the CPU usage noticeably worse than mine) if you hide native controls and disable automatic spellchecking. Or maybe we'll find that drawing native controls when using Skia/Metal is the problem. If you -- You are receiving this mail because: You are the assignee for the bug.
