Created attachment 176665 [details] Circular doodle for demonstration purposes SUMMARY When using the Freehand/Highlighter after selecting an region to screenshot it can get quite laggy. As an example, drawing spirals quickly goes from being smooth to just not. STEPS TO REPRODUCE 1. Select any to screenshot 2. Select Freehand or Highlighter tools under Edit... menu 3. Draw stuff on screen - like a spiral or whatever - without letting go 4. Observe lag OBSERVED RESULT Very laggy, spectacle at 100% CPU usage on a single core. Potentially "locking" you in screenshot selection overlay while it's processing. EXPECTED RESULT no lag pls SOFTWARE/OS VERSIONS Operating System: Fedora Linux 41 KDE Plasma Version: 6.2.4 KDE Frameworks Version: 6.8.0 Qt Version: 6.8.1 Kernel Version: 6.11.11-300.fc41.x86_64 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5700X 8-Core Processor Memory: 78.4 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 980 Ti/PCIe/SSE2 ADDITIONAL INFORMATION I have attached an artful doodle to give you an idea of what can cause the extreme slowdown.
Can reproduce.
Created attachment 176695 [details] spectacle-perf-2024-12-16-master.perfparser There's not a lot I can do about this in the near future. I've already tried very hard in the past to improve the performance of the freehand drawing tool. The more screens you have, the larger the drawing area is and the longer the total length of the line is, the slower it gets. Keeping the shadow enabled makes it worse, though not by a massive amount. I have attached a perfparser file in case anyone can come up with good ways to optimize this further. You can open it in Hotspot (the perf analysis app made by KDAB). During the recording of the perf data, I scribbled on an 1920x1080@1x screen for 3-4 seconds with a 4k@2.5x screen to the left and a 4K@2x screen to the right. I couldn't make the recording longer than this because of the 4000KB file size limit on this bug tracker, but the data should still be correct. From what I can see, these are the biggest CPU hogs: - qt_qimageScaleAARGBA_down_xy_sse4 (64.6%, used by some kind of QRunnable, maybe has something to do with QImage::transformed and QImage::scaled) - QImage::copy (17.1%, mostly used by AnnotationViewport::updatePaintNode) - QOpenGLFunctions::glTexSubImage2D (6.61%, mostly used by QRhiGles2::executeCommandBuffer, indirectly by QRhi::endFrame) It should be noted that updatePaintNode doesn't use QImage's CPU intensive copy and scaled functions for no reason. One of the things we have to be careful about is using too much GPU memory because if you run out of GPU memory, you just get a black screen with no indication as to why. Even now, there's no foolproof way to prevent running out of GPU memory, AFAIK. Right now what we do is draw on a QImage with QPainter and send all or a potentially scaled section of the image to the scene graph, depending on the screen and image device pixel ratios and how much would fit on the screen. Perhaps performance improvements could be made by reworking the annotation system to draw directly in the scene graph and later save the texture to a QImage? It's hard to say what is right at this point without further testing.
*** Bug 502332 has been marked as a duplicate of this bug. ***
*** Bug 506207 has been marked as a duplicate of this bug. ***