Created attachment 193278 [details] A problematic polygon Attached is a (modified) single polygon extracted from the 3rd party external pdf referenced in tdf#113050; I've cut it down to a single polygon and tweaked it a bit, so hopefully that's OK. It's a single, 125 point, polygon with a tiled image fill with an especially tiny image; it's taking VclProcessor2D::RenderMaskPrimitive2DPixel about 1.6s to render that on my Linux box (Radeon 540 GPU, 4k display, X under xfce) The original document has 3 of these polygons overlayed with a bunch of other smaller ones, so taking ~10 seconds to render the page (and then another 10 to render the thumbnail and by the time you're done ~50 seconds for it to settle after load). I suspect this is the slow paths that 6b8c157a0b4f3 avoids in some case. Maybe there's an opportunity to improve this for our case; it's got a complex boundary but because of the vast number of image repetitions, most of the images are entirely contained within the shape so probably don't need the clever processing of anything intersecting the boundary.
Reproduced that LO struggles when moving the shape around or when zooming. Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: ae798781ef4df7a1fdef13af0bc459bf4f6e7b4c CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded Also in 7.0.0.3, but much improved compared to 6.0.0.3 (it would completely freeze back then). Referenced commit in comment 0 is Luboš's 6b8c157a0b4f37a09fdbf656919b2df06a3abc3e
Adding some debug, I'm seeing a useful amount of time in RenderFillGraphicPrimitive2DImpl iterating over the space using the tiny 2x2 (or 1x1) tiles; I think calling the devices DrawBitmapEx for each one. I see with some debug added: RenderFillGraphicPrimitive2DImpl PreScaled=1 size: 2 x 2 RenderFillGraphicPrimitive2DImpl nOffsetX: 0 nOffsetY: 0 nBTop: -1 nBLeft: -1 nBHeight: 2 nBWidth: 2 nOTop:0 nOLeft: 0 nOHeight:452 nOWidth:539 RenderFillGraphicPrimitive2DImpl bottom true exit 1711246 RenderFillGraphicPrimitive2DImpl PreScaled=1 size: 2 x 2 RenderFillGraphicPrimitive2DImpl nOffsetX: 0 nOffsetY: 0 nBTop: -1 nBLeft: -1 nBHeight: 2 nBWidth: 2 nOTop:0 nOLeft: 0 nOHeight:452 nOWidth:539 RenderFillGraphicPrimitive2DImpl bottom true exit 1763805 RenderFillGraphicPrimitive2DImpl PreScaled=1 size: 2 x 2 RenderFillGraphicPrimitive2DImpl nOffsetX: 0 nOffsetY: 0 nBTop: -1 nBLeft: -1 nBHeight: 2 nBWidth: 2 nOTop:0 nOLeft: 0 nOHeight:452 nOWidth:539 RenderFillGraphicPrimitive2DImpl bottom true exit 1846516 RenderFillGraphicPrimitive2DImpl PreScaled=1 size: 1 x 1 RenderFillGraphicPrimitive2DImpl nOffsetX: 0 nOffsetY: 0 nBTop: 0 nBLeft: 0 nBHeight: 1 nBWidth: 1 nOTop:0 nOLeft: 1 nOHeight:213 nOWidth:254 RenderFillGraphicPrimitive2DImpl bottom true exit 1586536 RenderFillGraphicPrimitive2DImpl PreScaled=1 size: 2 x 2 RenderFillGraphicPrimitive2DImpl nOffsetX: 0 nOffsetY: 0 nBTop: -1 nBLeft: -1 nBHeight: 2 nBWidth: 2 nOTop:0 nOLeft: 0 nOHeight:452 nOWidth:539 RenderFillGraphicPrimitive2DImpl bottom true exit 1890982 RenderFillGraphicPrimitive2DImpl PreScaled=1 size: 1 x 1 RenderFillGraphicPrimitive2DImpl nOffsetX: 0 nOffsetY: 0 nBTop: 0 nBLeft: 0 nBHeight: 1 nBWidth: 1 nOTop:1 nOLeft: 0 nOHeight:20 nOWidth:24 RenderFillGraphicPrimitive2DImpl bottom true exit 2241 RenderFillGraphicPrimitive2DImpl PreScaled=1 size: 2 x 2 RenderFillGraphicPrimitive2DImpl nOffsetX: 0 nOffsetY: 0 nBTop: -1 nBLeft: -1 nBHeight: 2 nBWidth: 2 nOTop:0 nOLeft: 0 nOHeight:452 nOWidth:539 RenderFillGraphicPrimitive2DImpl bottom true exit 1804904 RenderFillGraphicPrimitive2DImpl PreScaled=1 size: 2 x 2 RenderFillGraphicPrimitive2DImpl nOffsetX: 0 nOffsetY: 0 nBTop: -1 nBLeft: -1 nBHeight: 2 nBWidth: 2 nOTop:0 nOLeft: 0 nOHeight:452 nOWidth:539 RenderFillGraphicPrimitive2DImpl bottom true exit 1880210 RenderFillGraphicPrimitive2DImpl PreScaled=1 size: 2 x 2 RenderFillGraphicPrimitive2DImpl nOffsetX: 0 nOffsetY: 0 nBTop: -1 nBLeft: -1 nBHeight: 2 nBWidth: 2 nOTop:0 nOLeft: 0 nOHeight:452 nOWidth:539 RenderFillGraphicPrimitive2DImpl bottom true exit 1827428 RenderFillGraphicPrimitive2DImpl PreScaled=1 size: 2 x 2 RenderFillGraphicPrimitive2DImpl nOffsetX: 0 nOffsetY: 0 nBTop: -1 nBLeft: -1 nBHeight: 2 nBWidth: 2 nOTop:0 nOLeft: 0 nOHeight:452 nOWidth:539 RenderFillGraphicPrimitive2DImpl bottom true exit 1822608 RenderFillGraphicPrimitive2DImpl PreScaled=1 size: 2 x 2 RenderFillGraphicPrimitive2DImpl nOffsetX: 0 nOffsetY: 0 nBTop: -1 nBLeft: -1 nBHeight: 2 nBWidth: 2 nOTop:0 nOLeft: 0 nOHeight:452 nOWidth:539 RenderFillGraphicPrimitive2DImpl bottom true exit 1811949 RenderFillGraphicPrimitive2DImpl PreScaled=1 size: 2 x 2 RenderFillGraphicPrimitive2DImpl nOffsetX: 0 nOffsetY: 0 nBTop: -1 nBLeft: -1 nBHeight: 2 nBWidth: 2 nOTop:0 nOLeft: 0 nOHeight:452 nOWidth:539 RenderFillGraphicPrimitive2DImpl bottom true exit 1805552 RenderFillGraphicPrimitive2DImpl PreScaled=1 size: 2 x 2 RenderFillGraphicPrimitive2DImpl nOffsetX: 0 nOffsetY: 0 nBTop: -1 nBLeft: -1 nBHeight: 2 nBWidth: 2 nOTop:0 nOLeft: 0 nOHeight:452 nOWidth:539 RenderFillGraphicPrimitive2DImpl bottom true exit 1776656 here the number after 'exit' is GetMonotonicTicks() difference from entry, so I think that's about ~1.8s each time! I also see 135510 calls to BaseProcessor2D::process (const BasePrimitive2D&) which is a heck of a lot!
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2a9b53bb9f85c2869c779dde36a2d77353fef14b tdf#160345 Slow rendering of filled polygon It will be available in 25.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.
Noel's fix makes a heck of a difference; both on this single polygon and the full page; it's now only taking a couple of seconds with X pegged. You can still hammer it if you try zooming a little.
(In reply to Dave Gilbert from comment #4) > Noel's fix makes a heck of a difference; both on this single polygon and > the full page; it's now only taking a couple of seconds with X pegged. > You can still hammer it if you try zooming a little. Confirm Observations A) Scrolling past the shape with zoom at say 450% is still slowish; Same for dragging the shape. B) Scrolling (at zoom) becomes worse when copying the shape and pasting it say 5 times. Even with 100% overlap with previous one Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 17e8dbead42e2d4b55815b1b7b2846b03d62a15d 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
(In reply to Telesto from comment #5) > (In reply to Dave Gilbert from comment #4) > > Noel's fix makes a heck of a difference; both on this single polygon and > > the full page; it's now only taking a couple of seconds with X pegged. > > You can still hammer it if you try zooming a little. > > Confirm > > Observations > A) Scrolling past the shape with zoom at say 450% is still slowish; Same for > dragging the shape. > B) Scrolling (at zoom) becomes worse when copying the shape and pasting it > say 5 times. Even with 100% overlap with previous one A bit hard to quantify, but comparing oldest of Win 25.2 repo with latest master, dragging has gotten faster. Ie. mouse cursor does not lag behind much. Zooming past 450% and back again seems to have improved, although it can not be called smooth. With multiple copies, scrolling is laggy when zoomed at around 300% (must be due to a certain visibility level of the fill images). I had a hunch the commits to bug 166715 might have an effect (last one from 26 June). Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 697fadb8f4efdc09091088261ca1b43984c029b4 CPU threads: 2; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
(In reply to Buovjaga from comment #6) > A bit hard to quantify, but comparing oldest of Win 25.2 repo with latest > master, dragging has gotten faster. Ie. mouse cursor does not lag behind > much. Zooming past 450% and back again seems to have improved, although it > can not be called smooth. With multiple copies, scrolling is laggy when > zoomed at around 300% (must be due to a certain visibility level of the fill > images). I had a hunch the commits to bug 166715 might have an effect (last > one from 26 June). Ah, nevermind, I don't know why I compared to oldest of 25.2 when the commit from comment 3 was not yet in. Comparing rather to oldest of 25.8 I don't see a difference.