the attached .wmf is incredibly slow to load, seems to spend most of its time in basegfx::tools::findCuts in trying to figure out a complicated clipping path
caolanm->thorsten: any good ideas about how to make this not so awesomely slow ? gimp/libwmf struggle a bit with it too, but are a few orders of magnitude faster nevertheless
(In reply to comment #1) > gimp/libwmf struggle a bit with it too, but are a few orders of magnitude > faster nevertheless yeah, that's this "let's flatten down all clips to Region" or somesuch madness going on, that's IMO from long-gone ancient times when Win16 was slow/inable to process polygonal clips. I had once improved the easy case (rectangular clips), will look into this one if there's a similarly easy quick fix - beyond that, the right way forward is to more or less import WMF actions as-is, to semantically equivalent SVM - or even better, get rid of this intermediate completely & render WMF, like we do for EMF+, and for SVG. ;)
(In reply to comment #0) > the attached .wmf is incredibly slow to load, seems to spend most of its time > in basegfx::tools::findCuts in trying to figure out a complicated clipping path Where is the attachment? Can you reattached it to bug ticket?
Created attachment 60604 [details] sample wmf Sorry for a delay, I had extracted the wmf from a mega-run over all fdo/ooo bugzilla .ppts files and couldn't find the exact one again to re-extract it :-) Found it again as the wmf embedded in the bugdoc ppt from https://issues.apache.org/ooo/show_bug.cgi?id=55877 Now attached standalone (compressed as it doesn't fit into fdo's size limit otherwise. Which is probably what happened the last time too, except I failed to see it had been rejected)
I can confirm this bug on platform LO 4 RC1, Version 4.0.0.1 (Build ID: 527dba6f6e0cfbbc71bd6e7b88a52699bb48799) See also bug 41522, is this a similar issue?
(In reply to comment #5) > I can confirm this bug on platform LO 4 RC1, Version 4.0.0.1 (Build ID: > 527dba6f6e0cfbbc71bd6e7b88a52699bb48799) > > See also bug 41522, is this a similar issue? Edit: the correct number is bug 45122. Ignore the typo in the line above.
Apologies for not having gotten around fixing this bug yet; unfortunately in future I'll have even less time at my disposal for this, so I'm freeing up ownership for other volunteers to take over.
Created attachment 87291 [details] another example
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: *Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later) https://www.libreoffice.org/download/ *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT *Update the version field *Reply via email (please reply directly on the bug tracker) *Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-04-01
Confirmed that trying to open attachment 60604 [details] (not by insert, but dragging to LibO) takes a couple of minutes. Win 7 Pro 64-bit Version: 5.0.0.0.alpha1+ (x64) Build ID: f3375fa07f27bd2ade519af3c07d69040d10eaa9 TinderBox: Win-x86_64@42, Branch:master, Time: 2015-04-22_23:38:50 Locale: fi_FI
*** Bug 45122 has been marked as a duplicate of this bug. ***
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Confirmed with v5.2.2.2 under ubuntu 16.04 x64.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dfe33fcd20d97e34ba7b7926a5a0c9a93e0e9960 Related: tdf#45820 polygon clipping during wmf load is ultra slow It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Is it possible to backport to 5.3.0?
above commit is only related to this, doesn't fix it, but I personally feel its the right direction to go, but needs investigation to see why, when enabled, there is visual differences
*** Bug 114197 has been marked as a duplicate of this bug. ***
example opens 1.30 min in Version: 6.0.4.2 (x64) Build ID: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf CPU threads: 4; OS: Windows 10.0; UI render: GL; Locale: ru-RU (ru_RU); Calc: CL
Repro Version: 6.3.0.0.alpha0+ Build ID: 20ea90a557b5bc744fd234e3a20ab1db484cf88b CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-03-22_03:21:58 Locale: nl-NL (nl_NL); UI-Language: en-US Calc: threaded
*** Bug 127632 has been marked as a duplicate of this bug. ***
The visual difference was already resolved with commit: https://gerrit.libreoffice.org/c/core/+/113423 I would like to reenable complex clipping, with next Merge Request.
The visual glitches were fixed with bug 141394
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/aa17ea3d36b8f1ea8cd3d2fb215e80051547439d tdf#37281 tdf#45820 tdf#48916 tdf#55058 EMF Implement complex clipping It will be available in 7.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.
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/8deb9b3d2f8781628db73d3b2a3c7939ea4fcc2d tdf#37281 tdf#45820 tdf#48916 tdf#55058 EMF Implement complex clipping It will be available in 7.1.3. 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.
Verified in Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: d4f116d9576453f5974eb63db37a33c59ac53bc9 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded @Bartosz, Thanks for fixing this issue!!