Bug 160345

Summary: Slow rendering of filled polygon
Product: LibreOffice Reporter: Dave Gilbert <freedesktop>
Component: graphics stackAssignee: Not Assigned <libreoffice-bugs>
Status: NEW ---    
Severity: normal CC: freedesktop, stephane.guillou, telesto
Priority: medium Keywords: perf
Version: 7.0.0.3 release   
Hardware: All   
OS: All   
See Also: https://bugs.documentfoundation.org/show_bug.cgi?id=140797
Whiteboard:
Crash report or crash signature: Regression By:
Bug Depends on:    
Bug Blocks: 108741    
Attachments: A problematic polygon

Description Dave Gilbert 2024-03-25 01:41:44 UTC
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.
Comment 1 Stéphane Guillou (stragu) 2024-05-28 12:24:00 UTC
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