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.
Now compared to 25.8.1 it is noticeably smoother. Might be the fix for bug 149592 Arch Linux Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b8a10164dca775cba85eafe63eac3fa1d8171f69 CPU threads: 16; OS: Linux 6.16; UI render: default; VCL: gtk3 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 10 Sept 2025
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c92f890cf517e8a2473f757d422d0f83c0d1f7be tdf#160345 skia native rendering of bitmap tiling It will be available in 26.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.
I'm seeing a regression on this test polygon, although it's not from Neil's latest patch (I tried reverting it and it still happens) If I display this test file, and slowly zoom out, at one point the entire object just disappears. Working on 25.2.6.2-1 fedora packages, failing on head (even with Neil's patch reverted). There's not much point me attaching a screen shot, at 180% it's visible, at 160% it's a blank sheet, even though the polygon is still listed in the navigator.
Ahem - sorry! N*oe*l !
(In reply to Dave Gilbert from comment #11) > Ahem - sorry! N*oe*l ! bibisect: # status: waiting for both good and bad commits # bad: [8eca4b5a8a94149a7ea05152fb01ec8c75c57d7c] source 04fa1e4bba2c852aaf0f7420fce5fdbb59a4fc5f git bisect bad 8eca4b5a8a94149a7ea05152fb01ec8c75c57d7c # status: waiting for good commit(s), bad commit known # good: [64d2e0b68d8aaf8a5e794152e832e48889673125] source 47a8ba44e619f0c80c0a1611d56f58df5f6575bd git bisect good 64d2e0b68d8aaf8a5e794152e832e48889673125 # bad: [03180e8540548f14160ad0e7f57a0c4555883d3d] source 20d4eda7ab8ddb09cda0b47d86694bf239273059 git bisect bad 03180e8540548f14160ad0e7f57a0c4555883d3d # bad: [1135ce5edf1e5f458517a5d825cc1a2a42f8f91f] source 6354829686a11f0bbcd86fba5eced9d15b76d2c4 git bisect bad 1135ce5edf1e5f458517a5d825cc1a2a42f8f91f # good: [269eb4cd3580db8de3b0f8a2d2c690401f27f8bc] source 6e870c040bb0f550c126f0fdeb2b9cd497658dd0 git bisect good 269eb4cd3580db8de3b0f8a2d2c690401f27f8bc # bad: [aa5176b2371bbe48500ab697e68af4963b9aef0f] source 225682b69a491600d8a5a574e2af8b01cac8a9e3 git bisect bad aa5176b2371bbe48500ab697e68af4963b9aef0f # bad: [f6be85ef9ad9ffdda48926e5f500dcd918897891] source 8cf9bdbadefaddd9fef9a13e19f519911ca99cc3 git bisect bad f6be85ef9ad9ffdda48926e5f500dcd918897891 # bad: [159fdb5946fdb8a9468b38f4c4213c9697b59b59] source 10599fd334e6459963a779c64fe75a68af2cdc22 git bisect bad 159fdb5946fdb8a9468b38f4c4213c9697b59b59 # bad: [cd41ac3dab14d2c2a3f8777089983e2fa2e16a75] source fc6d103827687ee424a3ac9c764278dd899ef714 git bisect bad cd41ac3dab14d2c2a3f8777089983e2fa2e16a75 # bad: [eb17bc929377062459ac1c0ac5a3886429504077] source 2180e365b9e4c4920e1526554bb99a1e37094523 git bisect bad eb17bc929377062459ac1c0ac5a3886429504077 # bad: [933145fa3525e7482df1be5f66a2b0578e1814fd] source cd93f83bbcba0379bf39f3a4e76b955b7fa368b5 git bisect bad 933145fa3525e7482df1be5f66a2b0578e1814fd # good: [ae15e7655ac2add79c75457976bc64bf25eb5e7d] source 4e469136136aed27df73a77080262b26b85f37f1 git bisect good ae15e7655ac2add79c75457976bc64bf25eb5e7d # first bad commit: [933145fa3525e7482df1be5f66a2b0578e1814fd] source cd93f83bbcba0379bf39f3a4e76b955b7fa368b5
This is Armin's: commit cd93f83bbcba0379bf39f3a4e76b955b7fa368b5 Author: Armin Le Grand (collabora) <Armin.LeGrand@collabora.com> Date: Thu Aug 7 21:02:41 2025 +0200 tdf#167831 avoid painting bitmap data with zero dimensions See task, there may be bitmap-filled objects in files that have a logical size of (0, 0), despite the bitmap having valid data. That leads to problems *inside* cairo paint, so I have to test and avoid that. Change-Id: I18db3b030fb5cdf77caa5afd1bf901095fa1c67b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189135 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com> reverting this fixes the problem. Which makes some sense - when your texture bitmap gets tiny you can't just remove it - you've got to plot something otherwise you lose the entire feature!
(In reply to Dave Gilbert from comment #13) > This is Armin's: > Good spotting dave. that should be a different bug i think?
(In reply to Noel Grandin from comment #14) > (In reply to Dave Gilbert from comment #13) > > This is Armin's: > > > > Good spotting dave. that should be a different bug i think? OK, Created tdf#168392