Bug 160345 - Slow rendering of filled polygon
Summary: Slow rendering of filled polygon
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
7.0.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:25.2.0
Keywords: perf
Depends on:
Blocks: Shapes
  Show dependency treegraph
 
Reported: 2024-03-25 01:41 UTC by Dave Gilbert
Modified: 2024-08-26 12:34 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
A problematic polygon (12.01 KB, application/vnd.oasis.opendocument.graphics)
2024-03-25 01:41 UTC, Dave Gilbert
Details

Note You need to log in before you can comment on or make changes to this bug.
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
Comment 2 Dave Gilbert 2024-06-23 00:53:19 UTC
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!
Comment 3 Commit Notification 2024-06-27 11:10:16 UTC
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.
Comment 4 Dave Gilbert 2024-06-27 15:52:42 UTC
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.