3-slide PPTX attachment 156822 [details] from bug 129675 has EMF in slide 3. There's bug with OpenGL (HW-ACC regardless): If I wait enough with just one click on slide 2 and not click again to advance slide, I may see slide 3. But if I click normally to advance, I don't come to see it in normal time and presentation ends. Seems to have started in 6.0, was good in 5.4.7, so I add bibisectRequest. Note: original PPTX is attachment 156821 [details] and trouble slide is 20 there.
The EMF on the third sheet loads very slowly. This started with author Thorsten Behrens <Thorsten.Behrens@CIB.de> 2017-08-21 22:44:30 +0200 committer Thorsten Behrens <Thorsten.Behrens@CIB.de> 2017-08-22 12:28:57 +0200 commit ebc11ae0b132eefd3b1b1a837a8d0ad3ba73b460 (patch) tree 599ae51a0a42b111f245697e7ad86b7f85681798 parent a3782f1152e4cf02f30003b5f96c7ba603a87db9 (diff) emfplus: cut over to new EMF+ renderer We're on par with the old functionality now (modulo a few smaller issues); overall QoS is much better, we get vector output on pdf and print, and the need for large offscreen bitmap rendering goes away. https://cgit.freedesktop.org/libreoffice/core/commit/?id=ebc11ae0b132eefd3b1b1a837a8d0ad3ba73b460 However the quality of the rendering of sheet 3 is quite bad before the commit
@Julien A perf graph would be nice. If reproducible on Linux with OpenGL
OpenGL is disabled for me.
The EMF+ graphic causing issues is available as attachment 156837 [details] from bug 129675, is it really an Impress issue here? Of just graphics stack for the EMF+? Kind of seems this is a dupe of bug 129675 A WinDbg trace (master at 6.4 branch) just opening the EMF+ shows it chews memory parsing a dashed line: 0a 00000071`0eb8c8e0 00007fff`7bc6ea07 ucrtbase!_malloc_base+0x36 0b 00000071`0eb8c910 00007fff`795da256 mergedlo!xstor_component_getFactory+0x1af287 0c 00000071`0eb8c940 00007fff`795d874e mergedlo!basegfx::B2DPolygon::operator!=+0x616 0d 00000071`0eb8c970 00007fff`795df63f mergedlo!basegfx::utils::createAreaGeometryForLineStartEnd+0x379e 0e 00000071`0eb8c9b0 00007fff`795db619 mergedlo!basegfx::B2DPolygon::setNextControlPoint+0x19f 0f 00000071`0eb8ca00 00007fff`795eaece mergedlo!basegfx::B2DPolygon::appendBezierSegment+0x1a9 10 00000071`0eb8ca90 00007fff`79a07c64 mergedlo!basegfx::utils::applyLineDashing+0x36e 11 00000071`0eb8cc70 00007fff`799ebfb6 mergedlo!drawinglayer::primitive2d::PolygonStrokePrimitive2D::create2DDecomposition+0xe4 12 00000071`0eb8cd80 00007fff`79a3d7db mergedlo!drawinglayer::primitive2d::BufferedDecompositionPrimitive2D::get2DDecomposition+0xa6
(In reply to V Stuart Foote from comment #4) > Kind of seems this is a dupe of bug 129675 Yes, now with your explanation. I opened it when that one was closed. Let's wait and see what's gonna happen there.
@Chris, seems like your call. If you'd like to close this and concentrate on bug 129675 (revisiting basegfx, and bringing in other EMF+ hands) think that would be fine. Stuart
Timur: are you able to test with Skia/Vulkan?
Linux Skia 7.1+ with SAL_ENABLESKIA=1 SAL_USE_VCLPLUGIN=gen: somewhat slow 3rd slide, like 3 secs, but seen. Linux without OpenGL or Skia, with or without HW ACC: same as with Skia. I tested also with EMF_PLUS_DISABLE=1 and it's fast so EMF+ is worse here. Windows Skia 7.1+: to load 3rd slide and to exit presentation, actually it takes 2 clicks both, I don't know why. Windows GDI/no Skia and no HW ACC: 3rd slide just takes a second more, so it's not ideal, but is acceptable. Windows GDI with HW ACC: 3rd slide takes 10 seconds to load and 6 to exit. My conclusion: - load in Lin is same with all options and acceptable, but it's worse with default EMF+ than without. - load in Win is very slow with Hardware Acceleration and strange requiring 2-clicks with Skia. So this should be kept open. I don't have Vulkan.
Dear Timur, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from https://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: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
No speed issues opening, or running presentation with Skia raster, or Vulkan rendering. Performance issues seem to WFM, as was see also bug 129675 Test doc attachment 156822 [details] shows weird handling of the EMF between the presentation console and the actual slide show canvas, which I think is bug 130478 For the 3 slide presentation--rendering quality of the gradient fills of the maps and for the dashed arc lines *differs* between renderings GDI+, CPU HA, Skia raster, Skia Vulkan. Including the "next slide" preview using different render path to the current slide and actual presentation--where both the Skia lib based modes drop lines in the gradient. And where CPU HA does not dash the arcs. =-testing-= Version: 7.4.2.3 (x64) / LibreOffice Community Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 07d303b74108debc9e2b9855a49d69bf156a91a9 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded