Description: Dragging a shape around on top of hi-resolution image is stutters (Skia/Raster) Steps to Reproduce: 1. Open the attached file 2. Select the shape and move it around in circles I only tested Skia/Raster Actual Results: Stuttering Expected Results: Smooth (as before) Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 220ef19df9de6ee7a99173a514402a9e701748d1 CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: nl-NL Calc: CL threaded not in Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 87b3b8e6990b394baa74aec8701cd097f6c0c646 CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded
Created attachment 201261 [details] Sample
Created attachment 201262 [details] Screencast
*** Bug 166969 has been marked as a duplicate of this bug. ***
Created attachment 201266 [details] system config with no issues with skia software based raster rendering Can't confirm. 2025-06-13 TB77 build Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 220ef19df9de6ee7a99173a514402a9e701748d1 CPU threads: 28; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Do you have the Snap-to-grid button enabled? I get a bit smoother movements with it off. Also, you're on Windows 10 but with what GPU and how much display RAM do you have for the skia software rendering to work with? Expect buffering the transparent background as the shape is moved would eat up memory. Maybe copy paste the System & Display panel clip from a run of dxdiag.exe, that will put this in context. Attaching DxDiag results with current modest hw.
For me, it is a matter of the option: Menu>Tools>Options>LibreOffice Draw>General>Use background cache BTW don't look so bad having the original object position in the view.
No issue on macOS either Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7fddf33f70b5e496ca7e3936a845d47b9deca027 CPU threads: 8; OS: macOS 14.7.4; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Well, re-checked again. The issue is somehow related to window size. For me it's bad * when maximized * often - but not always - when windowed. Really depending on Window size I mentioned - in comment 0 - that Build ID: 87b3b8e6990b394baa74aec8701cd097f6c0c646 being good. This actually not the case.
Bibisected to the following range: /win64-25.8 ((1d435a4a0...)|BISECTING) $ git bisect good f7282e38e9462a94d3db2d3c525a052dc632fd1f is the first bad commit commit f7282e38e9462a94d3db2d3c525a052dc632fd1f Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Sun Mar 2 11:06:11 2025 -0800 source 9b4dac8bf180f3fd5441b447a60439fb258854d4 source 9b4dac8bf180f3fd5441b447a60439fb258854d4 source 897d70c1f710c88f9c321cf72af739b21de427ca I suspect: https://gerrit.libreoffice.org/c/core/+/181906
(In reply to Telesto from comment #7) > Well, re-checked again. The issue is somehow related to window size. > > For me it's bad > * when maximized > * often - but not always - when windowed. Really depending on Window size > > I mentioned - in comment 0 - that Build ID: > 87b3b8e6990b394baa74aec8701cd097f6c0c646 being good. This actually not the > case. Hmmm. I cannot reproduce this bug with Skia/Raster even if I switch the document to full screen mode, minimize the LibreOffice sidebar, and zoom the document to 100% (to make the document content larger). Maybe the issue is only on x86_64 hardware?: Version: 26.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: fa860658fe987f6f599fe2782c69ecaa315e179d CPU threads: 8; OS: macOS 15.5; UI render: Skia/Raster; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded
(In reply to Patrick (volunteer) from comment #9) > (In reply to Telesto from comment #7) And, still waiting for Telesto to identify the GPU & display resources he's working with on Windows 10. If the GPU has driver issues (ski or GDI) or if there has minimal display RAM available--could be trouble there.
(In reply to Patrick (volunteer) from comment #9) This is windows issue, I think. I haven't seen it on macOS (comment 6)
The background image doesn't makes it little slower, but not essential. Sorry, I overlooked that The issue vanishes when hiding the status bar
(In reply to Telesto from comment #12) > The background image doesn't makes it little slower, but not essential. > Sorry, I overlooked that > > The issue vanishes when hiding the status bar Interesting, the status bar tracks both a cursor displacement for the Move shape, and the anchor position of the Position and Size dialog. Guess calculating those could be a bit of a load. Relieved when the Status Bar is hidden. Still seems a resource issue. Likewise, wouldn't expect macOS to be affected in general as Apple generally provisions these systems with sufficient graphics resources and keep their driver performant.
Created attachment 201290 [details] VerySleepy Stack (In reply to V Stuart Foote from comment #13) > Still seems a resource issue. Likewise, wouldn't expect macOS to be > affected in general as Apple generally provisions these systems with > sufficient graphics resources and keep their driver performant. Sure, it's resource issue. Yes, I'm using old machine (>10 years) with mid-end CPU at the time. So I surely notice this kind of quicker. Being a resource issue is the case of most of the performance bugs. If you throw enough resources at it, mostly appears to be fine. I initially stated that it's not seen on macOS. Well this isn't totally true: with Instruments CPU profiler attached I can surely observe the performance issue when dragging (Intel macbook). And it can be seen on the CPU profile aswell. Point being: this worked fine, until recently.
Same effect when drawing/resizing a shape/raster image in Writer
@Aron Would you mind to test this. The latest and greatest hardware is apparently able to cope with the high rate of flushes. Older systems can't handle it that well. Adding a profiler to process will make the bug a bit more noticeable on powerful systems, I guess