Description: Graphical tearing when scrolling in LO Draw in Windows. I was using the mousewheel, thumb in the scrollbar, doesn't matter how you scroll. Steps to Reproduce: 1. Launch LO Windows 2. Go to Draw 3. Draw anything at all, even just a basic shape 4. Scroll the page Actual Results: Severe tearing / disintegration of the image Expected Results: No such graphical anomaly. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 88ca6d7834a9d710dc124ee845fd3c270e33b59a CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
Created attachment 171165 [details] Tearing in Draw
@mwt, you are on Windows but what is the display resolution, and what is the os/DE scale factor?
Confirmed Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 88ca6d7834a9d710dc124ee845fd3c270e33b59a CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL RenderMethod: vulkan Vendor: 0x10de Device: 0xffe API: 1.2.155 Driver: 461.368.0 DeviceType: discrete DeviceName: Quadro K2000 Denylisted: no On a 1920x1200 px screen with os/DE at 100% scale factor.
No issue with default GDI rendering. And no issue with Skia "raster" rendering. Issue only with Skia Vulkan rendering this os & GPU.
Created attachment 171173 [details] Skia Vulkan rendering glitch when moving slider up pushing canvas view down
(In reply to V Stuart Foote from comment #2) > @mwt, you are on Windows but what is the display resolution, and what is the > os/DE scale factor? Not sure this answers your question, but I'm using two 1920x1080 standard resolution (non hi-DPI) monitors on Windows 10, and they're independent, not set up as a single 3840x1080 group.
Side note, I must use Vulkan rendering because going with just hardware rendering Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 88ca6d7834a9d710dc124ee845fd3c270e33b59a CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL still produces bug 117160 which leaves a 1-pixel-wide line top and left on a page when a Draw page has no margins (and I almost never have margins). If it wasn't for that bug I'd go with hardware rendering and be done with it.
I can't reproduce it in Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: da6c70efbc991f1fc61aace267dd4f972dedce6c CPU threads: 16; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-US Calc: threaded
(In reply to Xisco Faulí from comment #8) > I can't reproduce it in > > Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community > Build ID: da6c70efbc991f1fc61aace267dd4f972dedce6c > CPU threads: 16; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win > Locale: en-GB (en_GB); UI: en-US > Calc: threaded It's Vulkan only, and likely - speculative! - related to the recent Skia m91 bump https://gerrit.libreoffice.org/c/core/+/113978
Luboš Luňák committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/302fb4c1ec4a24112f9a2028be4d424891f10b4c Revert "update Skia to chrome/m91" (tdf#141680) It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 141277 has been marked as a duplicate of this bug. ***