https://bugs.documentfoundation.org/show_bug.cgi?id=154602
--- Comment #16 from Jeff Fortin Tam <nekoh...@gmail.com> --- Created attachment 193925 --> https://bugs.documentfoundation.org/attachment.cgi?id=193925&action=edit Sysprof 46 performance profiling capture Let me put some objective measurements into the mix here with a profiling measurement using Sysprof. I reproduced this by using the provided CSV sample above and pressing-and-holding the down arrow button on the keyboard of a 4K HiDPI (@ 2x) Intel Kabylike laptop running Wayland GNOME on Fedora 39, with the Flatpak flathub version of LibreOffice: Version: 24.2.2.2 (X86_64) / LibreOffice Community Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01 CPU threads: 8; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Flatpak Calc: threaded I will attach screenshots of the essentials of that sysprof capture. My naïve observations: * The overwhelming majority of time/efforts are spent in "PaintHelper" and "SdrPaintView" functions and the like, which ultimately spend a ton of time doing cairo_paint and cairo_fill everywhere. * It seems to be single-threaded, as per the CPU usage graphs. My gut feeling: it's probably spamming the backend as fast and often as keyboard input events are coming, without any throttling/smoothing. I don't think it makes sense for the app to be trying to respond to every event, 600 times per second (the 25-seconds sysprof recording shows 15 thousand function calls...). -- You are receiving this mail because: You are the assignee for the bug.
