Download it now!
Bug 136933 - Impress remains stuck Linux in advancing to the next slide in presentation mode
Summary: Impress remains stuck Linux in advancing to the next slide in presentation mode
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
7.0.0.3 release
Hardware: All Linux (All)
: high major
Assignee: Not Assigned
URL:
Whiteboard: target:7.1.0
Keywords: bibisectRequest, regression
Depends on:
Blocks:
 
Reported: 2020-09-21 14:23 UTC by sergio.callegari
Modified: 2020-10-05 19:24 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Presentation showing the issue. Try /all/ the presentation. (52.47 KB, application/vnd.oasis.opendocument.presentation)
2020-09-21 15:04 UTC, sergio.callegari
Details
gdbtrace.log (143.57 KB, text/plain)
2020-09-25 09:28 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sergio.callegari 2020-09-21 14:23:21 UTC
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
Comment 1 sergio.callegari 2020-09-21 15:04:58 UTC
Created attachment 165738 [details]
Presentation showing the issue. Try /all/ the presentation.
Comment 2 Timur 2020-09-22 10:14:38 UTC Comment hidden (obsolete)
Comment 3 Telesto 2020-09-23 07:20:36 UTC Comment hidden (obsolete)
Comment 4 Timur 2020-09-23 09:33:21 UTC Comment hidden (obsolete)
Comment 5 Timur 2020-09-23 10:07:41 UTC
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".
Comment 6 Buovjaga 2020-09-23 12:34:39 UTC Comment hidden (obsolete)
Comment 7 Timur 2020-09-23 13:39:07 UTC Comment hidden (obsolete)
Comment 8 Buovjaga 2020-09-23 13:48:20 UTC Comment hidden (obsolete)
Comment 9 Telesto 2020-09-23 18:58:52 UTC
Time in Skia Raster seems to be spend in
rtl_math_approxEqual
basegfx::utils::isPointOnLine
basegfx::utils::isPointOnPolygon
Comment 10 Telesto 2020-09-23 19:05:09 UTC Comment hidden (obsolete)
Comment 11 Xisco Faulí 2020-09-24 13:23:09 UTC Comment hidden (obsolete)
Comment 12 Xisco Faulí 2020-09-24 13:26:48 UTC
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
Comment 13 Xisco Faulí 2020-09-24 13:29:37 UTC Comment hidden (obsolete)
Comment 14 Xisco Faulí 2020-09-24 13:30:57 UTC
@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?
Comment 15 Timur 2020-09-24 14:16:13 UTC Comment hidden (obsolete)
Comment 16 Timur 2020-09-25 09:28:41 UTC
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!
Comment 17 Luboš Luňák 2020-09-25 09:51:31 UTC
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.
Comment 18 Timur 2020-09-25 10:16:56 UTC
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.
Comment 19 Luboš Luňák 2020-09-25 11:13:06 UTC
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.
Comment 20 Commit Notification 2020-09-29 07:56:10 UTC
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.
Comment 21 Commit Notification 2020-09-29 07:56:21 UTC
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.
Comment 22 Luboš Luňák 2020-09-29 08:00:21 UTC
The reporter's problem with slowness has been fixed for 7.1, closing.
Comment 23 Timur 2020-10-05 08:08:37 UTC
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).
Comment 24 sergio.callegari 2020-10-05 19:24:59 UTC
Seems OK for me in today's master, thanks.