Description: Currently on Windows 10, LibreOffice allows to enable hardware acceleration as well as use Skia for rendering. Enabling hardware acceleration, SVGs are rendered nicely on any zoom level. However activating Skia, SVGs are poorly rendered. I tested it with Writer, Impress and Draw, however I find Impress and activating full screen / presentation most the best option to reproduce the issue. I first added this bug as a comment to the existing bug 133016 but it was requested to report a new bug. I hope it's not a duplicate, still I found no one besides the mentioned one. Steps to Reproduce: 1. Enable Skia for rendering 2. Open LibreOffice Impress 3. Add an SVG image to the slide (e.g. the LibreOffice logo) 4. Start presentation mode 5. optional: repeat the steps with hardware acceleration but without Skia to see the difference Actual Results: SVG image poorly rendered Expected Results: SVG image nicely rendered as with default hardware acceleration Reproducible: Always User Profile Reset: No Additional Info: Version 7.4.0.2 (x64)
Created attachment 181932 [details] test ODP with SVG images inserted to single slide Can not confirm with 7.4.0.3 or current master. The attached ODP with a single slide and 3 SVG attachments pans cleanly in Skia Raster (software based) rendeering, and with an occasional cache glitch with Skia Vulkan (hardware accelerated) rendering. Quality matches GDI (CPU only rendering) or GDI w/Hardware Acceleration (CPU calls to GPU)--but the Skia based rendering is smoother pan. Version: 7.3.4.2 (x64) / LibreOffice Community Build ID: 728fec16bd5f605073805c3c9e7c4212a0120dc5 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 64be7052ba7e02e248412222098e07a5f4106456 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded RenderMethod: vulkan Vendor: 0x8086 Device: 0x8a52 API: 1.2.195 Driver: 0.404.1069 DeviceType: integrated DeviceName: Intel(R) Iris(R) Plus Graphics Denylisted: no
We need to know the GPU and driver details. And a screen clip or two of the issue how "SVGs are poorly rendered" would help. And when you say Skia do you mean Skia based Vulkan (replacement for OpenGL) or do you mean Skia with software only aka raster rendering? If your issue is with Skia Vulkan rendering, do you otherwise have good looking SVGs with Skia raster software only rendering. Toggle between the two modes of Skia rendering from the Tools -> Options -> View "Graphics Output" panel by selecting the 'Force Skia software rendering'. When checked that disables the Vulkan (aka OpenGL) accelerated rendering. Please copy and post the Help -> About details for the install having issue with SVGs, and also the "skia.log" from your user profile, e.g. C:\Users\<username>\AppData\Roaming\LibreOffice\4\cache\skia.log
Created attachment 181947 [details] Example image First of all, I added the example images as a zip file. It illustrates how the provided example odp file is rendered in presentation mode (once with Skia, once with hardware rendering). When referring to Skia rendering, I always refer to the 'Tools -> Options -> View -> Graphics Output' option. With 'hardware rendering' I refer to the non-Skia, but hardware acceleration while with 'Skia' I'm always referring to the 'use Skia for rendering' (i.e. OpenGL replacement) option with 'force Skia rendering' checked. Hardware rendering always produces nicely looking SVGs while Skia mode, which is enabled by default, does not. The skia.log file only contains two lines: RenderMethod: raster Compiler: Clang The GPU used is the internal Intel UHD Graphics of an i7-10510U CPU. Driver version is 30.0.101.1122. The full LO version information (I used both, 7.4 as well as 7.5 dev builds, issue is the same): Version: 7.4.0.2 (x64) / LibreOffice Community Build ID: 1512ce97d7ed39dce3121f7e15651fd8895f950e CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: threaded Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 5ac75131556b687a01517ce4520a05bb49c1d840 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL Please let me know in case you need any further information.
(In reply to Gibtnix from comment #3) > Please let me know in case you need any further information. Thanks, so your issue is when you are using Skia with Vulkan rendering? Or also Skia in its "Force Skia software rendering" (aka raster mode). The two Skia check boxes control it -- both checked is the software mode, the 'Use Skia for all rendering' box alone attempts Vulkan accelerated rendering. Neither checked uses legacy GDI rendering. The skia.log you list is from a system in software rendering mode, but for systems with driver/GPU issues that is a fall-back that can occur when a session in Vulkan mode aborts (the UI restarts). We handle poorly supported GPU/driver pairs with denylist--so they don't attempt to use Vulkan accelerated rendering. We either need the LibreOffice skia.log with Vulkan rendering (as I show in comment 1). Or you can use a utility like http://www.realtech-vr.com/home/glview and copy the driver and GPU details into a post here.
Thanks for the clarification. I did not know that there is a significant difference in using the force skia for rendering checkbox. I unchecked it and the skia.log now contains the following content: RenderMethod: vulkan Vendor: 0x8086 Device: 0x9b41 API: 1.2.196 Driver: 0.404.1122 DeviceType: integrated DeviceName: Intel(R) UHD Graphics Denylisted: no Hope this helps. Thanks for responding and let me know in case you need any further information.
(In reply to Gibtnix from comment #5) >... > Hope this helps. Thanks for responding and let me know in case you need any > further information. Yes thank you. And just to clarify--the bad SVG rendering is with Vulkan accelerated rendering, or *also* occurs with Skia software rendering? And, is this only with Impress? Or are the other modules also affected--Draw, Writer, or Calc? Thanks!
Sorry, forgot to add in my last comment: Switching the different Skia options does not change anything, the effect is the same. Currently, the issue is mostly visible in the full screen mode of Impress, i.e. it is actually impossible to compare this to Draw. Still, I will perform further tests to reproduce the issue in editing mode and compare this to Draw. If I succeed in reproducing the issue with Draw, I will add another comment.
[Automated Action] NeedInfo-To-Unconfirmed
Created attachment 181999 [details] Incorrect font rendering as well I performed some more tests. It seems to be a particular issue related to the full screen mode of LO Impress. Besides this, the rendering seems to be correct. Still, I also noticed that the fonts are incorrectly rendered. Depending on the size, the glyphs are somehow incorrectly resized. I attached an example image using Arial 20 pt bold (top, incorrect) and also Arial 20 pt regular (bottem, correct). This issue only occurs with Skia enabled and is the same for both Skia modes, i.e. with the default hardware rendering, everything looks fine. I don't know in how far these two issues are related, still I found it rather interesting that both are caused by Skia rendering.
(In reply to Gibtnix from comment #9) Sorry, no idea what you meant by "full screen mode of LO Impress"; did you mean while presenting a single slide, or during edit with app frame "maximized"? Also I don't see an issue with the font rendering you show, are these text strings rendered to SVG and then inserted as image layers? If they are LO text boxes? Where the artificial bold applied by LibreOffice increases stroke width, and glyphs are still 20 pt., your clip would need to show side by side comparisons. Is concern with Skia rendering a size issue, or a positioning issue (which just got some work for bug 150462). But then let's leave text box rendering out of this bug and submit a new issue for that. With Vulkan and attachment 181932 [details] the field of SVG LO triangles have some noticeable dropouts (that to me is a GPU buffering issue) but that doesn't occur with Skia raster rendering.
Created attachment 182016 [details] Side-by-side comparison of incorrect font rendering With full screen mode I mean the presentation mode, not the regular editing mode maximized, sorry for the confusion. The rendered strings are regular text boxes. The side-by-side comparison is added. I did not want to mix this bug report with another one. I just thought that the incorrect SVG rendering might be related to this font issue and that it should be worth mentioning.
Created attachment 182026 [details] test ODP single slide with a single multi-element SVG This single slide ODP has a single multi-element SVG on canvas rotated. STR 1. Open LO and enable Vulkan rendering 2. Open this single slide ODP 3. launch Slide show 4. observe the full screen presentation mode I am seeing significant drop-out visual glitches in the individual triangles to a lesser extent, in edit mode with slide canvas zoomed, there is some drop out of fill within individual triangle elements.
Moved the font rendering with Skia for presentation mode to bug 150609
Created attachment 182029 [details] camera shot of presentation on 7.3.6.1 with Skia Vulkan rendering glitch
(In reply to V Stuart Foote from comment #14) > Created attachment 182029 [details] > camera shot of presentation on 7.3.6.1 with Skia Vulkan rendering glitch Version: 7.3.6.1 (x64) / LibreOffice Community Build ID: 92b673af3a5e8f7cf4716be88dfaca424612f244 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded same rendering issues with 7.4.1alfa and current master against 7.5.0 =-ref-= skia.log RenderMethod: vulkan Vendor: 0x8086 Device: 0x8a52 API: 1.2.195 Driver: 0.404.1069 DeviceType: integrated DeviceName: Intel(R) Iris(R) Plus Graphics Denylisted: no
No improvement in the SVG dropouts after updating to latest Intel driver for this GPU Driver Version 31.0.101.2111 which updates Vulkan driver to be: RenderMethod: vulkan Vendor: 0x8086 Device: 0x8a52 API: 1.3.215 Driver: 0.404.2111 DeviceType: integrated DeviceName: Intel(R) Iris(R) Plus Graphics Denylisted: no in Impress edit mode, continue to see some artifacts in Skia Vulkan rendering as the canvas is panned. But the Skia Raster mode is clean. Looking at it in Vulkan rendering and attached to WinDbg, it does look to fail graphics watchdog when going into full screen presentation, which suggests this GPU should be denylisted, except this is pretty generic GPU. Maybe not too much available video RAM but it should handle this simple Vulkan rendering. Makes me think we have an implementation issue in here somewhere.
Created attachment 182032 [details] WinDbg stacktrace of LO 7.4.1 buffer overflow when launching into Impress presentation with Skia Vulkan enabled on nVidia K2000 GPU nVidia 473.47 driver RenderMethod: vulkan Vendor: 0x10de Device: 0xffe API: 1.2.175 Driver: 473.188.0 DeviceType: discrete DeviceName: Quadro K2000 Denylisted: no On this system, the triangles are filled in presentation mode without dropouts. But the edges ofeach triangle are noticibly sawtoothed. While those on the edit canvas are smooth. But this GPU driver will also abort via watchdoog process 60% of launches into presentation with Vulkan enabled. updating to nVidia driver 473.81 results in this Vulkan skia.log: RenderMethod: vulkan Vendor: 0x10de Device: 0xffe API: 1.2.175 Driver: 473.324.0 DeviceType: discrete DeviceName: Quadro K2000 Denylisted: no but no improvement. The SVG objects edges remain saw-toothed. @Luboš,* -- I was able to catch a substantive WinDbg stacktrace with symbols (attached) --but not sure it is of any real help.
The bug is still there in LibreOffice 7.5.x. Here is a presentation example, with an SVG equation obtained from TexMaths. In SlideShow mode, with Skia rendering enabled (in Windows or Mac OS X) the SVG rendering is distorted. When Skia is disabled (or in Linux) the SVG rendering in SlideShow mode is correct.
Created attachment 187722 [details] Presentation example with SVG image from TexMaths