Description: Crash if i open Preferences and click on Application Colors in take 1 minute or more with beachball on mac os Sierra 10.12.3 on MacBook Pro 17" early 2011 Steps to Reproduce: 1.open Preferences 2.click on Application Colors 3.Wait Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/602.4.8 (KHTML, like Gecko) Version/10.0.3 Safari/602.4.8
I can't reproduce it in Version: 5.4.0.0.alpha0+ Build ID: d3b5bd4a07a619db6bee1c39c32280ac3c620532 CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group To be certain the reported issue is not related to corruption in the user profile, could you please reset your Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and re-test? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present
Version: 5.4.0.0.alpha0+ Build ID: 7abb4dda1d2e08a428c768c7706046adbf88c860 CPU threads: 2; OS: Mac OS X 10.12.3; UI render: default; Locale: fr-FR (fr_FR.UTF-8); Calc: group The application colour dialog displays within approximately 10 seconds - no hang
With Version: 5.3.0.3 Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1 Threads CPU : 2; Version de l'OS :Mac OS X 10.12.3; UI Render : par défaut; Moteur de mise en page : nouveau; Locale : fr-FR (fr_FR.UTF-8); Calc: group however, although it doesn't hang, I do get the dreaded spinning beachball for approximately 1 minute before the colour dialog is displayed. Performance regression - confirming
(In reply to Alex Thurgood from comment #3) > With > > Version: 5.3.0.3 > Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1 > Threads CPU : 2; Version de l'OS :Mac OS X 10.12.3; UI Render : par défaut; > Moteur de mise en page : nouveau; > Locale : fr-FR (fr_FR.UTF-8); Calc: group > > however, although it doesn't hang, I do get the dreaded spinning beachball > for approximately 1 minute before the colour dialog is displayed. > > Performance regression - confirming Then it should be closed as RESOLVED WORKSFORME and whiteboard 'backportRequest:5:3' added. Could you please bisect it to find which commit fixed it so we can ask for it to be backported ?
Created attachment 131961 [details] LLDB Backtrace I'm conforming the approximately 10 sec delay with 5.4.0.0.alpha0+. The 10 sec delay is still way to long in my opinion (and the BT is suggesting likewise). BT done with: Version: 5.4.0.0.alpha0+ Build ID: e7391ca132a9964dc9d870039a104abec044d357 CPU threads: 4; OS: Mac OS X 10.12.4; UI render: default; Locale: en-US (en_US.UTF-8); Calc: group
Created attachment 132238 [details] details of bibisect in daily Linux dbgutil repository I ran some tests with the daily Linux dbgutil bibisect repository on debian-stretch. As I see neither the slowness that Alex reported in comment 3 nor the fastness that he reported in comment 2, I suspect that the bibisect results in this environment are not worth much, and I am leaving keyword bibisectRequest. Anyway, here are the results of my reverse bibisect (good means slow, bad means faster) ... commit date s-h SAL_USE_VCLPLUGIN: (elapsed,CPU secs) -------- ---------- -------- ------------------------------------- good 6f431dc2 2017-01-27 2be42d94 gen : (31,30.43); gtk3 : (44,34.06) bad 44f8a607 2017-01-28 41323222 gen : (23,22.41); gtk3 : (29,23.54)
I'm experiencing also a lag on Windows opening Application Colors with: Version: 5.4.0.0.alpha0+ (around 7 seconds) Build ID: 1670cc25bc2771e87f7956a4b0dd634abaa4128b CPU threads: 4; OS: Windows 6.19; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-03-22_23:28:42 Locale: nl-NL (nl_NL); Calc: CL and with: Version: 5.3.0.0.alpha1+ (around 5 seconds) Build ID: 43b5ca69aa545cf93eded55258d92d651917815f CPU Threads: 4; OS Version: Windows 6.2; UI Render: GL; Layout Engine: new; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-11-18_05:27:05 Locale: nl-NL (nl_NL); Calc: CL but not with: Version: 5.3.0.0.alpha1 Build ID: f4ca1573fcf445164c068c1046ab5d084e1b005f CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Locale: nl-NL (nl_NL); Calc: CL Changing summary accordingly. Aron would you mind to take a look.
This performance issue comes from two already reported bugs. First is the change in bug 104312. This is basically switching to the new color picker, or some related change. The other part is bug 105428: for me the delay goes from 5s to 25s with the commit there. Since only one duplicate can be referenced, I'm adding the other as see also. *** This bug has been marked as a duplicate of bug 104312 ***
@Aron I'm still noticing a 3 sec delay with the latest daily: Version: 5.4.0.0.alpha1+ Build ID: 9d320ec4d818f86e58a15fd46248026502b1cc94 CPU threads: 4; OS: Windows 6.2; UI render: default; TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2017-05-09_01:27:12 Locale: en-US (nl_NL); Calc: single
Telesto, thank you for retesting. Let's reopen this bug report for this particular issue. While bug 104312 didn't affect Linux, this does, and is definitely linked to the many color pickers on that screen. I think the importance can be lowered to medium/normal, as the delay is shorter, and the options are not visited often.
Created attachment 134215 [details] Process Monitor Output The share\palette directory is visited quite a lot. Every palette file (for example) breeze.soc and classic.sog will be accessed 46 times (in 1 sec) Version: 6.0.0.0.alpha0+ Build ID: 18f513145477d4621290253d936dad7a40ee4c05 CPU threads: 4; OS: Windows 6.19; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-06-21_06:40:38 Locale: nl-NL (nl_NL); Calc: CL
Would removing the unnecessary preview widgets (bug 108139) help alleviate some of the lag?
*** This bug has been marked as a duplicate of bug 112532 ***