Description: I have a presentation that is OK with LibO 6.4.x, but cannot be presented with 7. On LibO 7, the presentation starts normally, then as I progress from slide to slide, the time taken to move to the next slide increases on an on, up to a point where asking for the next slide gets cpu usage up to 100% and the time taken for advancing is 30-40 seconds. Seen on linux (kubuntu 20.04, intel graphics, LibO 7.0.2.1 (unselectable as of today from version list in bug tracker). Steps to Reproduce: 1. Start presentation 2. Keep advancing to next slide Actual Results: After about 10-15 slides, cpu usage goes up to 100% at slide transitions and slide actually changes after > 30s Expected Results: Presentation is fine as in LibO 6.4.x Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: PresentationDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes Note that switching on/off opengl is not possible from LibO 7.0 options interface
Created attachment 165738 [details] Presentation showing the issue. Try /all/ the presentation.
Test in Linux LO 7.1+: sometimes works, sometimes crash. Test in Windows 7.1+: very slow, crash. I didn't test previous LO, but I put regression based on report.
(In reply to Timur from comment #2) > Test in Linux LO 7.1+: sometimes works, sometimes crash. > Test in Windows 7.1+: very slow, crash. > I didn't test previous LO, but I put regression based on report. Is this unrelated to Skia? There is a possibility of two different bugs
Bug reporting should be minimal, worse in BZ is multiplying bugs when uncertain. I reproduced w/ and w/o Skia so no need to divert. Unlike the reporter, I had crashes in oldest and latest LO 6.4, and also in older LO. Seems that LO 6.0 oldest doesn't crash, so bibisect is to be tried there.
I tried to bibisect in Linux 6.0, bibisect passes, but I couldn't confirm the commit. Maybe there are changes, sometimes on the 2nd slide, sometimes on 4th. I marked normal exit as "good" and all crashes as "bad".
No problem for me with latest master or bibisect repositories for 7.0 and 7.1 on Win. Version: 7.1.0.0.alpha0+ (x64) Build ID: dba1a27be2438b5dbd1f8d253acb3850c9c044da CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: default; VCL: win Locale: fi-FI (fi_FI); UI: en-US Calc: threaded
(In reply to Telesto from comment #3) > (In reply to Timur from comment #2) > > Test in Linux LO 7.1+: sometimes works, sometimes crash. > > Test in Windows 7.1+: very slow, crash. > > I didn't test previous LO, but I put regression based on report. > > Is this unrelated to Skia? There is a possibility of two different bugs I have a crash in Windows with 7.1+ Skia. So yes, this may be different from Linux. Interesting there is no crash with LO 7.0 beta Skia. No crash without Skia, just flickering. This is Fade Smoothly transition, we have bug 91456 for that. (Buovjaga, please test with Skia). In Linux, unlike the reporter, I had crashes in oldest and latest LO 6.4, and also in older LO. LO 6.0 oldest doesn't crash, LO 6.0 latest does. I don't have Skia in Linux.
(In reply to Timur from comment #7) > (Buovjaga, please test with Skia). Crashes on Win with Skia/Raster and on Linux with Skia/Vulkan Timur: you can use Skia on Linux with: SAL_ENABLESKIA=1 SAL_USE_VCLPLUGIN=gen path/to/soffice
Time in Skia Raster seems to be spend in rtl_math_approxEqual basegfx::utils::isPointOnLine basegfx::utils::isPointOnPolygon
For the record: * Issue appears on slide 4. * It's not a crash, (on Windows), only lots of CPU time being wasted.. Version: 7.1.0.0.alpha0+ (x64) Build ID: 52a49f9e480ca03e231cfda82640a928393131c9 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL -> Leaving in the middle if this is also the problem of the original poster. I slightly doubt it.. but we will see soon enough
Skia is available since 7.0, how is it possible this issue is reproducible in 6.0.7.3 ?
On linux, this used to crash due to bug 134647 but it's fine for me in Version: 7.1.0.0.alpha0+ Build ID: 121771e37f7e2de41cd5643475861062bf25627b CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
We should use this report to either focus on the skia ( win only issue ) or on the linux issue. In case it crashes with skia and on linux, I think the root cause is different
@Sergio Callegari, since you are using KDE, does it crash for you if you launch LibreOffice from commandline with SAL_USE_VCLPLUGIN=gen path/to/soffice?
As I wrote, it crashes from 6.0 to 7.1+ in Linux for me. I agree that this may be split to Skia and not, but this bug started as Linux, so let's keep Linux here. Needs some wrap-up.
Created attachment 165830 [details] gdbtrace.log I opened bug 137018 for Skia crash Win/Lin, so this bug remains for GDI bug in Linux (No Skia nor OpenGL in Tools-Options-View). I reproduced this starting from LO 6.0 latest and in 7.1+ Linux GTK3 (unlike Xisco). So it's New, regardless that Sergio should respond (testing with 7.1+ master). I noticed it doesn't always crash, like in 1st LO run, better to run a few times. With SAL_USE_VCLPLUGIN=gen it doesn't crash for me. Crashes also with debug build. I attach gdbtrace. Last message in console is: warn:sfx.view:5103:5103:sfx2/source/view/viewfrm.cxx:3236: SID_SIDEBAR state requested, but no task pane child window exists for this ID!
The original description clearly says that it only takes a long time, there's no crash. So the splitting is done backwards, this bugreport should be about the slowness (for which I already have a fix). If you have any crashes, that should be filled as a separate bugreport.
Luboš, thanks for comment, but not clear for me. I split Skia to bug 137018 . Here is Linux GDI, slowness and crash. If anything is changed here, we can open a new bug for the rest. But now, not prudent.
It is not slowness and crash. The original report says slowness, it doesn't say anything about a crash. And the slowness is not Skia or Linux, it affects both. So this bugreport should be about slowness (Skia or not). If you have a crash, that should be separate.
Luboš Luňák committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/748723883a626b499f605d7a5bad92e25b69a0e4 Revert "don't split polypolygon in canvas if not needed" (tdf#136933) It will be available in 7.1.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.
Luboš Luňák committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6f224a17dbf635319503a81ce4038b1ae2ad6de0 make vclcanvas try directly VCL for drawing stroked polygon (tdf#136933) It will be available in 7.1.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.
The reporter's problem with slowness has been fixed for 7.1, closing.
Sergio, please test with LO master containing fix. https://dev-builds.libreoffice.org/daily/master/current.html https://libreoffice.soluzioniopen.com/daily-version/ (I revert the title to slowness).
Seems OK for me in today's master, thanks.