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.
Which desktop environment are you using?
You can force different backends by launching from the command line:
If you want to debug it, you can try callgrind, but note that it is REALLY slow:
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.
(In reply to Buovjaga from comment #1)
> 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
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.
Created attachment 128363 [details]
Calc started with 'gen'
Created attachment 128364 [details]
Calc started with 'gtk'
Created attachment 128365 [details]
Calc started with 'gtk3'
Created attachment 128366 [details]
Calc started with 'kde4'
"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....
Resolves: rhbz#1373933 gtk 3.21 emits a lot more "style-set" signals
since gtk3 commit of...
Author: Matthias Clasen <firstname.lastname@example.org>
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.
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.