https://bugs.documentfoundation.org/show_bug.cgi?id=173514
--- Comment #3 from V Stuart Foote <[email protected]> --- All rendering of LibreOffice on Windows builds now uses Chromium projects skia graphics libs. Legacy MS GDI+ rendering paths were dropped and mostly stripped out. Also by skia libs, we either use Vulkan hardware acceleration (very dependent on GPU hw and supporting driver) or we use software based raster framing (less GPU overhead, but can impact CPU resources). The skia software rendering is now enabled by default at the 26.8 release. Releases through the 26.2 builds enabled skia Vulkan hw rendering, and the skia lib rendering could be fully disabled to fall back to GDI+ rendering. That said, LibreOffice is very dependent on GPU driver support for either skia raster framing, or of more robust skia Vulkan hardware acceleration. The truth is that many "legacy" GPUs are not well supported by their manufacturers, and when in use via skia rendering paths (either hw accelerated Vulkan, or CPU assisted software raster framing) on a Windows WDDM 3.1 or 3.2 display manager, they choke. We keep the skia libs "milestone" releases current with the Chromium project (what makes its way into Google Chrome browser), which benefits newer/more robust GPUs with current driver support, but there is an impact on marginal systems. My six year old Samsung laptop with 10th gen CPU (i7-1065G7) and "latest" Iris iGPU suffers, while my daily driver desktop with nVidia GeForce 4060 dGPU and current driver support of Vulkan has no issues. So, again, your best bet for any robustness is to ensure skia Vulkan hw acceleration is kept disabled. And, to keep the font previews disabled. Check your AMD driver currency from time to time. We've asked the ESC to dig deeper into the skia libs performance issue to try to tease out what could be adjusted to reduce the bottleneck(s), time will tell. -- You are receiving this mail because: You are the assignee for the bug.
