Description: When using SKIA rather than hardware acceleration when there are several high-resolution images on a Draw Page, holding down the mouse button and the control button to zoom in and out, or just using the mouse button to scroll up and down, produces lag. The image continues to move in and out or up and down long after I finish using the mouse, and I can't do anything else until the redraw eventually finishes. I have anti-aliasing enabled both with and without SKIA. Regardless of rendering method used, the image, when zoomed in and scrolled up and down, has rendering artifacts on it (image isn't updated so leaves a banded effect). Scrolling again removes it. Steps to Reproduce: 1. Launch LO Draw 2. Incorporate multiple high-resolution images on a slide (I used 3 1920x1080 images on a 21.33 x 21.33 canvas) 3. Control-Mouse to zoom in and out. If you move the mouse very slowly, it's fine. Scroll as one would expect to scroll producing a document, and it's laggy. Actual Results: Document locks up while the redraw finishes and/or continues to zoom in and out long after I let up on the mouse. Hardware rendering isn't necessarily fast or smooth, but at least it remains responsive. Expected Results: Program should react without lag to zooming up and down and in and out. Reproducible: Always User Profile Reset: No Additional Info: nvidia 1050 TI graphics card, 3770K I-7 processor. Could very well be that the processor simply is no longer beefy enough to keep up, but that doesn't explain why I don't have similar lag issues with high-resoluition images using Krita, paint.net, and Inkscape. Version: 7.0.0.0.beta2 (x64) Build ID: 1c213561a365b5666167321de68c9977500c9612 CPU threads: 8; OS: Windows 10.0 Build 20150; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
Created attachment 162322 [details] Example file
I do confirm slowness, but only with Skia Vulkan; it's quite OK with Skia software mode @Stuart Can you confirm this
Bisected slowness for GDI mode in bug 134241 / bug 134242. Maybe the same thing
I cannot reproduce any particular slowness, and I cannot reproduce any rendering artifacts. Can you provide a test document and specific steps to reproduce the problem? Also, this below doesn't say "Skia" anywhere. > Version: 7.0.0.0.beta2 (x64) > Build ID: 1c213561a365b5666167321de68c9977500c9612 > CPU threads: 8; OS: Windows 10.0 Build 20150; UI render: default; VCL: win > Locale: en-US (en_US); UI: en-US > Calc: CL
(In reply to Luboš Luňák from comment #4) > I cannot reproduce any particular slowness, and I cannot reproduce any > rendering artifacts. Can you provide a test document and specific steps to > reproduce the problem? > > Also, this below doesn't say "Skia" anywhere. > > > Version: 7.0.0.0.beta2 (x64) > > Build ID: 1c213561a365b5666167321de68c9977500c9612 > > CPU threads: 8; OS: Windows 10.0 Build 20150; UI render: default; VCL: win > > Locale: en-US (en_US); UI: en-US > > Calc: CL I don't control what the description says when I hit the button to paste the configuration from LibreOffice. Program it to reflect the use/non-use of Skia if that's what you want. I'll get something to you in a bit.
Created attachment 162376 [details] Image without artifacts in LO Draw Pictured is a Sims4 mesh map in LibreOffice Draw for a mod I'm making. There are no artifacts on this image, it's appearing as it should.
Created attachment 162378 [details] Image with artifacts This is the image with artifacts, zoomed in and scrolled. Notice the gray lines banding across the clouds. These remain until the image is scrolled or zoomed again, an act which can very well create yet more artifacts.
Created attachment 162379 [details] My Skia Setup My skia setup. I'm using hardware acceleration with anti-aliasing, and not using Skia at all. The same artifacts occur when using Skia, including when forcing Skia software rending, but zooming and scrolling is dead slow using it.
Created attachment 162380 [details] My sample file My sample file.
And also something that seems to be a problem when I list bugs for LibreOffice, people seem to have Linux on the brain. I'm using Windows and the bug needs to be tested in Windows: Version: 7.0.0.0.beta2 (x64) Build ID: 1c213561a365b5666167321de68c9977500c9612 CPU threads: 8; OS: Windows 10.0 Build 20150; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL See above: ----OS: Windows 10.0 Build 20150------------
Using Telesto's test file, I can not confirm an issue with Skia Vulkan rendering on Windows 10 Ent 64-bit. Zoom steps are crisp (Zoom bar clicks or <Ctrl>+<mouseWheel>. Likewise when zoom with GDI rendering, with or without Hardware Acceleration, no delays and zoom steps are snappy all the way to 3000%. Version: 7.0.0.0.beta2 (x64) Build ID: 1c213561a365b5666167321de68c9977500c9612 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 Skia configuration... RenderMethod: vulkan Vendor: 0x10de Device: 0xffe API: 1.1.119 Driver: 442.296.0 DeviceType: discrete DeviceName: Quadro K2000 Blacklisted: no However for this os/DE driver & GPU hardware, there is an issue when I place Skia rendering in raster mode. The Zoom function (<Ctrl>+<scrollWheel>; or 'Zoom in' button on zoom bar) takes progressively longer to complete each step. There is a noticible lag with Skia raster mode rendering. Can get well ahead of the rendering (i.e. until the Zoom factor reaches its 3000% max in Draw). Get this Stack Trace while the zoom step processes... 0:021> ~* kp 0 Id: 237c.2438 Suspend: 1 Teb: 00000042`dc1e1000 Unfrozen # Child-SP RetAddr Call Site 00 00000042`dcb8a9d0 00007ffd`2c0dd874 skialo!SkColorFilters::Blend+0x8a4d 01 00000042`dcb8ab90 00007ffd`2c114bb1 skialo!SkColorFilters::Blend+0x12f44 02 00000042`dcb8aca0 00007ffd`2c10f669 skialo!SkMatrix::get9+0x28a1 03 00000042`dcb8acd0 00007ffd`2c15e131 skialo!SkRegion::quickContains+0x13a9 04 00000042`dcb8adc0 00007ffd`2c15e551 skialo!SkFont::getHinting+0x136f1 05 00000042`dcb8ae80 00007ffd`2c07d7d0 skialo!SkFont::getHinting+0x13b11 06 00000042`dcb8b3c0 00007ffd`2c07fcfc skialo!SkMatrix::get+0x1d60 07 00000042`dcb8c2d0 00007ffd`2c031a3d skialo!SkRect::sort+0x212c 08 00000042`dcb8d290 00007ffd`2c031ff9 skialo!SkRRect::getBounds+0x3dd 09 00000042`dcb8d4b0 00007ffd`2c05e523 skialo!SkRRect::getBounds+0x999 0a 00000042`dcb8d6b0 00007ffd`2c05a9dd skialo!SkCanvas::onDrawImage+0x353 0b 00000042`dcb8d880 00007ffd`28b1ef21 skialo!SkCanvas::drawImage+0xfd 0c 00000042`dcb8d960 00007ffd`28b1d7bd mergedlo!SkiaSalGraphicsImpl::isOffscreen+0x7b1 0d 00000042`dcb8db10 00007ffd`2879d643 mergedlo!SkiaSalGraphicsImpl::drawTransformedBitmap+0x14d 0e 00000042`dcb8dc90 00007ffd`2879d7c2 mergedlo!OutputDevice::DrawTransformBitmapExDirect+0x173 0f 00000042`dcb8ddf0 00007ffd`26bcfc7f mergedlo!OutputDevice::DrawTransformedBitmapEx+0x102 10 00000042`dcb8e0b0 00007ffd`26bcd43f mergedlo!drawinglayer::processor2d::TextAsPolygonExtractor2D::processBasePrimitive2D+0x10a1f 11 00000042`dcb8e1f0 00007ffd`26bb7753 mergedlo!drawinglayer::processor2d::TextAsPolygonExtractor2D::processBasePrimitive2D+0xe1df 12 00000042`dcb8e2f0 00007ffd`26bcd248 mergedlo!drawinglayer::processor2d::BaseProcessor2D::process+0x123 13 00000042`dcb8e3d0 00007ffd`26bb7753 mergedlo!drawinglayer::processor2d::TextAsPolygonExtractor2D::processBasePrimitive2D+0xdfe8 14 00000042`dcb8e4d0 00007ffd`26bcd248 mergedlo!drawinglayer::processor2d::BaseProcessor2D::process+0x123 15 00000042`dcb8e5b0 00007ffd`26bb7917 mergedlo!drawinglayer::processor2d::TextAsPolygonExtractor2D::processBasePrimitive2D+0xdfe8 16 00000042`dcb8e6b0 00007ffd`27df02ff mergedlo!drawinglayer::processor2d::BaseProcessor2D::process+0xb7 17 00000042`dcb8e740 00007ffd`27df061f mergedlo!sdr::contact::ObjectContactOfPageView::DoProcessDisplay+0x58f 18 00000042`dcb8e950 00007ffd`27e27837 mergedlo!sdr::contact::ObjectContactOfPageView::ProcessDisplay+0x5f 19 00000042`dcb8e980 00007ffd`27f1b5ae mergedlo!SdrPageWindow::RedrawAll+0x167 1a 00000042`dcb8ea70 00007ffd`27f22b1e mergedlo!SdrPageView::CompleteRedraw+0x8e 1b 00000042`dcb8eac0 00007ffd`240f3db8 mergedlo!SdrPaintView::CompleteRedraw+0xce 1c 00000042`dcb8eb60 00007ffd`240a0243 sdlo!sd::FrameView::WriteUserDataSequence+0x12cb8 1d 00000042`dcb8ebc0 00007ffd`240c3893 sdlo!sd::DrawView::CompleteRedraw+0xc3 1e 00000042`dcb8ec00 00007ffd`2859a7c6 sdlo!sd::FrameView::IsLayerMode+0x203 1f 00000042`dcb8ec70 00007ffd`2859b398 mergedlo!VirtualDevice::`vbase destructor'+0x356 20 00000042`dcb8ed10 00007ffd`2859a150 mergedlo!vcl::Window::ImplCallPaint+0x198 21 00000042`dcb8edb0 00007ffd`2859b3ba mergedlo!vcl::PaintBufferGuard::~PaintBufferGuard+0x2a0 22 00000042`dcb8ee50 00007ffd`2859a150 mergedlo!vcl::Window::ImplCallPaint+0x1ba 23 00000042`dcb8eef0 00007ffd`2859b3ba mergedlo!vcl::PaintBufferGuard::~PaintBufferGuard+0x2a0 24 00000042`dcb8ef90 00007ffd`2859a150 mergedlo!vcl::Window::ImplCallPaint+0x1ba 25 00000042`dcb8f030 00007ffd`2859b3ba mergedlo!vcl::PaintBufferGuard::~PaintBufferGuard+0x2a0 26 00000042`dcb8f0d0 00007ffd`2859a150 mergedlo!vcl::Window::ImplCallPaint+0x1ba 27 00000042`dcb8f170 00007ffd`2859b3ba mergedlo!vcl::PaintBufferGuard::~PaintBufferGuard+0x2a0 28 00000042`dcb8f210 00007ffd`2859a150 mergedlo!vcl::Window::ImplCallPaint+0x1ba 29 00000042`dcb8f2b0 00007ffd`2859b3ba mergedlo!vcl::PaintBufferGuard::~PaintBufferGuard+0x2a0 2a 00000042`dcb8f350 00007ffd`2859a150 mergedlo!vcl::Window::ImplCallPaint+0x1ba 2b 00000042`dcb8f3f0 00007ffd`2859b3ba mergedlo!vcl::PaintBufferGuard::~PaintBufferGuard+0x2a0 2c 00000042`dcb8f490 00007ffd`2859b4c6 mergedlo!vcl::Window::ImplCallPaint+0x1ba 2d 00000042`dcb8f530 00007ffd`28a107f2 mergedlo!vcl::Window::ImplHandlePaintHdl+0xd6 2e 00000042`dcb8f580 00007ffd`2b6abaae mergedlo!Scheduler::ProcessTaskScheduling+0x342 2f 00000042`dcb8f640 00007ffd`2b6a8386 vclplug_winlo!create_SalInstance+0x72e 30 00000042`dcb8f670 00007ffd`2b6a7eb1 vclplug_winlo+0x18386 31 00000042`dcb8f700 00007ffd`28a25754 vclplug_winlo+0x17eb1 32 00000042`dcb8f730 00007ffd`27864118 mergedlo!Application::Execute+0x164 33 00000042`dcb8f790 00007ffd`28a34817 mergedlo!SfxTabPage::set_visible+0x54e8 34 00000042`dcb8f9d0 00007ffd`27885399 mergedlo!ImplSVMain+0x67 35 00000042`dcb8fa00 00007ff6`1f7b105b mergedlo!soffice_main+0xf9 36 00000042`dcb8fab0 00007ff6`1f7b1308 soffice!main+0x1b 37 00000042`dcb8fae0 00007ffd`9bdf7bd4 soffice!main+0x2c8 38 00000042`dcb8fb20 00007ffd`9d6cce51 KERNEL32!BaseThreadInitThunk+0x14 39 00000042`dcb8fb50 00000000`00000000 ntdll!RtlUserThreadStart+0x21
(In reply to mwtjunkmail from comment #5) > > > > > Version: 7.0.0.0.beta2 (x64) > > > Build ID: 1c213561a365b5666167321de68c9977500c9612 > > > CPU threads: 8; OS: Windows 10.0 Build 20150; UI render: default; VCL: win > > > Locale: en-US (en_US); UI: en-US > > > Calc: CL > > I don't control what the description says when I hit the button to paste the > configuration from LibreOffice. Program it to reflect the use/non-use of > Skia if that's what you want. > @mwtjunkmail -- It has been. When you drop out of Skia (Vulkan or raster) and fall back to GDI rendering--this is what you'd see "render: default; VCL: win" The NEEDINFO remains to you. Need your Skia log (ideally when Vulkan rendering is enabled) found in ---> %APPDATA%\LibreOfficeDev\4\cache And, details from a run of msinfo32.exe: top few lines of the Summary panel, and also the top few from the Components -> Display panel.
Under \AppData\Roaming\LibreOfficeDev\4\cache I see this: opencl_devices opencl_profile opengl_device I'm running device hardware rendering, as mentioned before, not running Skia. Which one of these is supposed to be the Skia log? And where on this would I see Vulkan active or not? https://i.imgur.com/EPxS55D.png
I don't know what constitutes "first few lines" so here is a snapshot of the first bit of my msinfo32.exe information minus my user name. https://i.imgur.com/SYVx0F6.png
Okay, I fooled around with the settings until a Skia log was produced. This is what was in it: RenderMethod: raster Compiler: MSVC Slow as crap which is why I stuck with hardware rendering.
This is the Skia log when I selected Skia but not force skia software rendering: RenderMethod: vulkan Vendor: 0x10de Device: 0x1c82 API: 1.2.133 Driver: 451.192.0 DeviceType: discrete DeviceName: GeForce GTX 1050 Ti Blacklisted: no Equally slow as crap, still produced visual artifacts when scrolling as shown in my previous attachments.
I'd also recommend using my sample file that I attached rather than Telesto's. Mine's 4x the size.
Confirmed the Horizontal lines as the Draw page of attachment 162380 [details] is scrolled--both Skia Vulkan rendering, and Skia raster. Bands appear at the top edge as page is scrolled up or down across the top edge of the canvas frame. And, with Skia software raster rendering the hang on zoom steps (<Ctrl>+mouse wheel, or Zoom bar) is very noticible. Skia Vulkan also slows, but not to the point of stopping. I did have on crash out of Skia Vulkan rendering with fall back to Skia raster with today's TB77 build of master/7.1.0 Version: 7.1.0.0.alpha0+ (x64) Build ID: 010713e65ccade7b682c219707c8db3d864145c1 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
This is not Skia-specific. I can reproduce both the drawing problems and slowness with other drawing backends as well. And LO 6.4 works fine in both regards, so this is most likely a recent regression, so it would be nice if somebody could bisect this. Brief profiling points to this group of commits as the possible culprits: https://cgit.freedesktop.org/libreoffice/core/commit/?id=6806616023242aded27b1fae8637d32c9626d472 https://cgit.freedesktop.org/libreoffice/core/commit/?id=425125e31f9053e0e4895fb13e1e267ec5d26487 https://cgit.freedesktop.org/libreoffice/core/commit/?id=b435c4fe82e77a82fde6464d6722281e5fc4f394
(In reply to Luboš Luňák from comment #19) > This is not Skia-specific. I can reproduce both the drawing problems and > slowness with other drawing backends as well. And LO 6.4 works fine in both > regards, so this is most likely a recent regression, so it would be nice if > somebody could bisect this. Brief profiling points to this group of commits > as the possible culprits: > > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=6806616023242aded27b1fae8637d32c9626d472 > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=425125e31f9053e0e4895fb13e1e267ec5d26487 > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=b435c4fe82e77a82fde6464d6722281e5fc4f394 Bug 134242 point to a similar commit, not exactly the once above, but same author/same date/ same context
I've improved the Skia performance problems with zooming with https://git.libreoffice.org/core/+/3d37d591377fe532fc0d32e9fbc8e57b8ded6768%5E%21 , but I'm fairly certain that the actual performance and drawing problems here come from the soft edge feature I linked above.
(In reply to Luboš Luňák from comment #21) > I've improved the Skia performance problems with zooming with > https://git.libreoffice.org/core/+/ > 3d37d591377fe532fc0d32e9fbc8e57b8ded6768%5E%21 , but I'm fairly certain that > the actual performance and drawing problems here come from the soft edge > feature I linked above. I think you're on to something there. I set the soft edges to the three images on my test document to 0, then tried: 1. hardware rendering 2. Skia 3. Force Skia Software Rending and by far the fastest was (2). No artifacts and fast. Good catch. So does that mean we can look at https://bugs.documentfoundation.org/show_bug.cgi?id=134213 now? :)
Luboš Luňák committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1db7decf3fb172542f5fce03ce7bf0cb310d1ffc limit bitmap size for glow/softedge effects to visible area (tdf#134237) It will be available in 7.1.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.
With 7.2.0.0 alpha 0 Version: 7.2.0.0.alpha0+ (x64) Build ID: f313e27fb7f2d42247407e26e16f264e30f87ca5 CPU threads: 8; OS: Windows 10.0 Build 20262; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Using Skia and AA: The zooming/panning/scrolling is now faster. Using Hardware rendering and AA: No real improvement. Both: The banding effect when you scroll still occurs.
Still happening with Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 7eb289c49cc7245ef3001a39be0c15d06bbe875b CPU threads: 8; OS: Windows 10.0 Build 21296; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
Still happening in Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: e642179f466c899365fc9539a8aca66b39fea39a CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
Artifacts are gone. Works now okay for me in: Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: d29958304b3ff87115ed5af16b482327ea05ce14 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Also working fine using: Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: d29958304b3ff87115ed5af16b482327ea05ce14 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Marginally (but tolerably) slower compared to the other methods, otherwise fine: Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: d29958304b3ff87115ed5af16b482327ea05ce14 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded