Bug 103324 - user interface freezes on opening dialogs and context menus
Summary: user interface freezes on opening dialogs and context menus
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.1.5.2 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: perf
Depends on:
Blocks: GTK3
  Show dependency treegraph
 
Reported: 2016-10-19 00:54 UTC by Vangel Ajanovski
Modified: 2016-12-01 23:13 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Calc started with 'gen' (39.74 KB, image/png)
2016-10-30 16:41 UTC, Vangel Ajanovski
Details
Calc started with 'gtk' (44.77 KB, image/png)
2016-10-30 16:42 UTC, Vangel Ajanovski
Details
Calc started with 'gtk3' (38.51 KB, image/png)
2016-10-30 16:42 UTC, Vangel Ajanovski
Details
Calc started with 'kde4' (51.83 KB, image/png)
2016-10-30 16:43 UTC, Vangel Ajanovski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vangel Ajanovski 2016-10-19 00:54:43 UTC
How to reproduce:

1. Open Libreoffice Calc (it opens relatively fast)
2. Enter few numbers in several cells (all is OK, formatting is OK)
3. Press CTRL+1 to open cell options (or right click).
4. The dialog shows after 5-10 seconds, but it is all BLACK, after 30-40 seconds it is finally drawn in an instant.
5. After the dialog is drawn completely, it is not a problem to change options and switch between tabs.
6. After closing the dialog, to open the same dialog once again it will be a couple of seconds faster, but still too slow.

The problem is not just with this dialog, but many dialogs (e.g. image properties, character formatting, paragraph formatting, ...). Some open faster, some slower.

This problem started to occur for the first time in the last month or so, but I have not been paying too much attention because I didn't have much work to do with office documents, just reading. 

So I am not able to remember and pinpoint what changed so that the situation got worse.

I am using Archlinux on a Intel i5 with 4GB RAM, so it's not due to not having enough resources. This happens even on empty documents with just 2 lines of text.

The problem affects all Libreoffice apps.

Writing pure text and reformatting text just by using the toolbar is OK.

I have tried several options to attempt and fix the problem, without success:
- deleted the .config profile
- reinstalled libreoffice (both -still and -fresh versions)
- reinstalled all libraries that libreoffice package depends on
- increased/decreased memory settings of libreoffice
- changed hardware acceleration and opengl options
- changed system themes and fonts
- have tried the most recent Zen and Mainline kernels available as arch packages in order to try with different graphics driver versions

I don't have any other ideas what to try to solve this issue, but it is quite a problem if you have to wait a minute on every picture you paste, just to be able to rescale it or reposition it in the document.

I don't know how to debug it, but since I am an advanced linux user, any idea what to do and try in order to be able to pinpoint why this happens is welcome.
Comment 1 Buovjaga 2016-10-29 18:44:08 UTC
Which desktop environment are you using?

You can force different backends by launching from the command line:
SAL_USE_VCLPLUGIN=gtk libreoffice
SAL_USE_VCLPLUGIN=gtk3 libreoffice
SAL_USE_VCLPLUGIN=gen libreoffice

If you want to debug it, you can try callgrind, but note that it is REALLY slow:
https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_callgrind_trace

As there is no "libreoffice-debug" package for Arch, I guess you would have to test with this: http://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@70-TDF-dbg/current/

(For sure, first test with the master build normally, to see, if the problem exists in this fresh version)

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided more information.
Comment 2 Vangel Ajanovski 2016-10-30 16:38:09 UTC
(In reply to Buovjaga from comment #1)
> Which desktop environment are you using?

XFCE4 (4.12)

> You can force different backends by launching from the command line:
> SAL_USE_VCLPLUGIN=gtk libreoffice
> SAL_USE_VCLPLUGIN=gtk3 libreoffice
> SAL_USE_VCLPLUGIN=gen libreoffice

This is what i tested yesterday.
gen - cell properties dialog via shortcut (CTRL+1) opens instantly, obviously the interface is not so nice, but the issue is that main toolbar is transparent and one can see the windows behind. Otherwise it's OK.
gtk3 - when clicking CTRL+1 - nothing happens for up to 10 seconds, that it shows a black rectangle (with the size of the dialog window), and stays black a couple of minutes, and suddenly everything is shown an then it works OK. On subsequent opening of the same dialog it is a bit faster, but still too slow. 
gtk - works fast, the interface is OK, but there are some minor issues (for example, you can not see the frame indicating the current cell in Calc), which is also annoying.
kde4 - similar transparency problems like with gen, otherwise it works OK.

But then after it I saw that there was an update of gtk3 and all it's issues seem to be solved with the latest version gtk3. 
The rest of the described issues in gen, gtk and kde4 modes are still present.

Now, knowing that the problem might have been due to gtk3 itself, this is the history of the recent updates of gtk3.
[2016-05-28 22:04] [ALPM] upgraded gtk3 (3.20.4-2 -> 3.20.6-1)
[2016-08-07 03:41] [ALPM] upgraded gtk3 (3.20.6-1 -> 3.20.8-1)
[2016-08-18 05:13] [ALPM] upgraded gtk3 (3.20.8-1 -> 3.20.9-1)
[2016-10-02 12:59] [ALPM] upgraded gtk3 (3.20.9-1 -> 3.22.1-1)
[2016-10-14 17:21] [ALPM] upgraded gtk3 (3.22.1-1 -> 3.22.1+8+ge11df6c-2)
[2016-10-29 21:47] [ALPM] upgraded gtk3 (3.22.1+8+ge11df6c-2 -> 3.22.2+4+gc54f348-1)

If it's due to gtk3, I think that the problem might have started occuring with the upgrades in august (line 2 or 3 above)

I will try later to find and install those specific gtk3 versions, to try and reproduce the issue, and do a DEBUG with callgrind and post the results here again.
Comment 3 Vangel Ajanovski 2016-10-30 16:41:50 UTC
Created attachment 128363 [details]
Calc started with 'gen'
Comment 4 Vangel Ajanovski 2016-10-30 16:42:16 UTC
Created attachment 128364 [details]
Calc started with 'gtk'
Comment 5 Vangel Ajanovski 2016-10-30 16:42:39 UTC
Created attachment 128365 [details]
Calc started with 'gtk3'
Comment 6 Vangel Ajanovski 2016-10-30 16:43:06 UTC
Created attachment 128366 [details]
Calc started with 'kde4'
Comment 7 Caolán McNamara 2016-12-01 21:29:31 UTC
"I saw that there was an update of gtk3 and all it's issues seem to be solved with the latest version gtk3", so things are ok again then I assume.

This might have been the same issue fixed by....

https://cgit.freedesktop.org/libreoffice/core/commit/?id=ef7abe81df10cb8a8c04afbb1fbe700f94e73f04

Resolves: rhbz#1373933 gtk 3.21 emits a lot more "style-set" signals
also deb#837356

since gtk3 commit of...

commit 0f116135f4a5033ce4e9dfa19f10624701fa615c
Author: Matthias Clasen <mclasen@redhat.com>
Date:   Fri May 6 10:12:14 2016 -0400

    Avoid emitting ::style-set by name

    GtkStyle is deprecated, but we still emit ::style-set quite
    a bit, so lets at least not be slow while doing it.
Comment 8 Vangel Ajanovski 2016-12-01 23:13:13 UTC
I can confirm that this issue with gtk3 is fixed, now I am running gtk3 3.22.4-1.

The other mentioned issues that I noticed when trying to run as gen, gtk and kde4 are still present. (transparent toolbars or transparent menu or invisible frame on the current cell). I suppose a separate bug report is needed for those.