Version 5.1.3 is quite unresponsive on my macOS 11.4. Perhaps sluggish is a better adjective, because the software does indeed respond. By sluggish, I mean that every action is delayed significantly, yet probably never more than 1 second. Only when I’ve entered the chart view, and specifically the pedigree view, does the software run as normal. 5.1.2, however, runs perfectly.
Gramplets can bog Gramps down severely. Particularly the ones that do a lot of calculation. Even when they are not the topmost gramplet.
Deep Connections & Pedigree are 2 that I really like but cannot afford to leave running.
There are a lot of places that add-ons can be running. And it is a lot of work to turn them all off just for a test. Instead, you can disable them all in 1-step and see if performance is restored.
Try closing Gramps and start it from the command line (via Terminal in macOS) using the Safe Mode switch.
If performance go back up, quit the Gramps in safe mode and go back the regular version to start turning off Gramplets… in the Dashboard, and the Sidebar & Bottombar of every doggone View, and any that are undocked. Just leave the Filter Gramplet but Clear & re-Find it too. (All these new View modes could add to overhead too.)
But use common sense. If you see a Gramplet doing something complex, it is a good possibility as ‘the Culprit.’
I take that to mean that 5.1.2 runs perfectly on macOS 11.4. Did you install the .dmg versions of 5.1.3 and 5.1.2 (as opposed to MacPorts or Homebrew)? If so, maybe the difficulty can be isolated to something that changed in 5.1.3, but otherwise maybe there are other issues?
I am still on mac OS 10.14.6 and was thinking about upgrading, but now I will wait until this issue is sorted out.
Can you mention how many people you have in your family tree?
UPDATE: Fullscreen especially makes Gramps lag.
What resolution screen are you using and what are the specifications of your Apple computer, does it use a SSD(Solid state drive) instead of a mechanical hard drive or is the Gramps family tree located on a network drive?
Does exporting your Gramps family tree and importing it into a new family tree , then testing give the same result as the original?
Do you have the same issue using the Example.gramps family tree?
Can you mention how many people you have in your family tree?
At the time, I had very few. I have since expanded using 5.1.2, but the issue persists when I enter a new tree with zero members.
What resolution screen are you using and what are the specifications of your Apple computer, does it use a SSD(Solid state drive) instead of a mechanical hard drive or is the Gramps family tree located on a network drive?
At the moment, there is no difference between fullscreen and non-fullscreen. Both are just as bad. Resolution is 2560 x 1600, and the specs are as follows:
1.1 Ghz Intel Core i3
8 GB 3733 Mhz LPDDR4X
Intel Iris Plus Graphics 1536 MB
SSD
If Sync(.com) is considered a network drive, then yes, the tree is indeed stored on one; however, I did create a new test tree locally and the issue persisted.
Does exporting your Gramps family tree and importing it into a new family tree , then testing give the same result as the original?
Yes, unfortunately.
Do you have the same issue using the Example.gramps family tree?
I tried downloading the example.gramps from github by clicking example.gramps and then download, but all I managed to do was open a Safari tab containing a bunch of code. I’m not too sure how to work my way around github.
I can’t say I have experienced what these people are reporting in general. This is limited specifically to Gramps 5.1.3. Besides, these reports seem to be concerning mainly the first Big Sur update. Version 11.4 is only a month old.
You may want to try a couple of general troubleshooting steps:
Open Activity Monitor before launching Gramps 5.1.3. Keep an eye on the cpu usage as you work with Gramps and see if some process goes to 100% usage when the lags occur. Let us know if you find something.
Open Console and launch Gramps 5.1.3. Watch for a flurry of system log messages when lags occur in Gramps. Copy and paste the messages if you see something repeating.
Open Activity Monitor before launching Gramps 5.1.3. Keep an eye on the cpu usage as you work with Gramps and see if some process goes to 100% usage when the lags occur. Let us know if you find something.
No process seems to go to 100% usage. The lag is constant, except whenever I am operating within the certain subsections such as “Charts”, yet both CPU and RAM seem to be taking it rather easy as far as I can tell.
Open Console and launch Gramps 5.1.3. Watch for a flurry of system log messages when lags occur in Gramps. Copy and paste the messages if you see something repeating.
So, I opened Console and pretended to do stuff on Gramps 5.1.3., but can’t make sense of it.
First attempt:
standard 18:30:31.652410+0200 Gramps NSApp cache appearance:
-NSRequiresAquaSystemAppearance: 1
-appearance: (null)
-effectiveAppearance: <NSCompositeAppearance: 0x600003bb3900
(
“<NSAquaAppearance: 0x600003bb3780>”,
“<NSSystemAppearance: 0x600003be5280>”
)>
standard 18:30:31.685583+0200 Gramps SignalReady: pid=39552 asn=0x0-0x2e82e8
standard 18:30:31.686129+0200 Gramps SIGNAL: pid=39552 asn=0x0x-0x3048168
standard 18:30:42.256237+0200 Gramps LSExceptions shared instance invalidated for timeout.
Second attempt:
standard 18:39:34.148114+0200 Gramps CHECKIN: pid=39672
standard 18:39:34.157929+0200 Gramps CHECKEDIN: pid=39672 asn=0x0-0x2ea2ea foreground=1
standard 18:39:34.166136+0200 Gramps Received configuration update from daemon (initial)
standard 18:39:34.173845+0200 Gramps FRONTLOGGING: version 1
standard 18:39:34.174055+0200 Gramps Registered, pid=39672 ASN=0x0,0x2ea2ea
standard 18:39:34.176841+0200 Gramps BringForward: pid=39672 asn=0x0-0x2ea2ea bringForward=1 foreground=1 uiElement=0 launchedByLS=1 modifiersCount=1 allDisabled=0
standard 18:39:34.176907+0200 Gramps BringFrontModifier: pid=39672 asn=0x0-0x2ea2ea Modifier 0 hideAfter=0 hideOthers=0 dontMakeFrontmost=0 mouseDown=0/0 seed=0/0
standard 18:39:34.177295+0200 Gramps BringForward: pid=39672 asn=0x0-0x2ea2ea
standard 18:39:34.177468+0200 Gramps SetFrontProcess: asn=0x0-0x2ea2ea options=0
standard 18:39:34.197432+0200 Gramps Current system appearance, (HLTB: 2), (SLS: 1)
standard 18:39:34.201488+0200 Gramps No persisted cache on this platform.
standard 18:39:34.202461+0200 Gramps Failed to copy the SysCfgDict MG key with error: 0
standard 18:39:34.205720+0200 Gramps Post-registration system appearance: (HLTB: 2)
standard 18:39:34.290941+0200 Gramps Registering for test daemon availability notify post.
standard 18:39:34.293216+0200 Gramps notify_get_state check indicated test daemon not ready.
standard 18:39:34.293364+0200 Gramps notify_get_state check indicated test daemon not ready.
standard 18:39:36.052702+0200 Gramps NSApp cache appearance:
-NSRequiresAquaSystemAppearance: 1
-appearance: (null)
-effectiveAppearance: <NSCompositeAppearance: 0x600002da3280
(
“<NSAquaAppearance: 0x600002da3100>”,
“<NSSystemAppearance: 0x600002dee000>”
)>
standard 18:39:36.079097+0200 Gramps SignalReady: pid=39672 asn=0x0-0x2ea2ea
standard 18:39:36.079742+0200 Gramps SIGNAL: pid=39672 asn=0x0x-0x3056362
standard 18:39:52.297085+0200 Gramps LSExceptions shared instance invalidated for timeout.
standard 18:40:53.180710+0200 Gramps Entering exit handler.
standard 18:40:53.180784+0200 Gramps Exiting exit handler.
I see there was about a 2 second gap before the following message appeared (in your second attempt):
Do these messages seem to correlate with the lags you experience?
I would guess that this message is related to Gramps use of the GTK windowing toolkit. I wonder perhaps if the GTK theme that Gramps wants to use is damaged or missing in the 5.1.3 distribution? Or something else along those lines? Perhaps the bundled version of GTK doesn’t play well with macOS 11?
Who packaged the 5.1.3 dmg? Perhaps they can help?
