Strange slowdowns Eeschema 5.1.8 on Mac

Recently upgraded from 5.1.7 to 5.1.8 on MacOS Catalina, Mac Pro (2019), and also on Mac Pro 5,1 running El Capitan.

Eeschema is now pausing (with spinning wheel) after certain operations such as dragging, adding wires, deleting objects. I have noticed the following:

This occurs with with schematics in the 10’s of parts. If I delete half the parts on a schematic with the slowdown, then the behavior improves.

  • If I start with a fresh project and schematic and start adding and connecting (for example) resistors in a netowrk, the same behavior is noticeable after ~40-50 connected parts.

  • If a new connection is created, the junction dot appears after the pause. Likewise for removing a wire from a junction.

  • Not all operations are affected. For example, Moving a part doesn’t cause the pause, but dragging the same part does.

Strangely, reverting to Kicad 5.1.7 does not fix the problem, even though I never experienced the problem under 5.1.7 before the upgrade.

All files are local. No network drives. No Dropbox. I installed KiCad 5.1.8 under parallels and don’t see this behavior.

Thanks for any insight,

Dave

I had the exact same issue not long ago with the beachball popping up after almost every action in KiCAD, but I cannot recall what I did to fix it.

I THINK I tried removing KiCAD completely (both the app and the application support folder) and installing fresh.

I tried the same and no change. And I just now tried installing 5.1.8 on a Macbook Pro running Catalina that previously did not have kicad. Same result. It can’t be imaginary.

I’ve seen this on all 3 Macs I have access to, on two upgrades from 5.1.7 and a fresh install. I’d be grateful for any insights.

I thought there may be an issue with my files, so I pulled in a sample file–OLIMEX A64-OlinuxIno, and it has the same behavior.

This may be fixed in the next “testing” build for 5.1.x, it most won’t be available until tomorrow to try.

Could you try the latest “testing” build of 5.1.x from https://kicad-downloads.s3.cern.ch/index.html?prefix=osx/testing/5.1/

2020-12-14 or newer.
Such as this unified release
https://kicad-downloads.s3.cern.ch/osx/testing/5.1/kicad-5.1-unified-20201213-235403-61076aa1df-10_14.dmg

I also have a noticeable slowdown with the Olinuxino A64, but I also expect that with a board of that complexity on my old PC.

I pulled down the build, and I do not observe the problem with this build.

However, Kicad can’t seem to recognize the libraries, although i can see them where Kicad is looking. So the shematics have no symbols. So, either the problem has been fixed, or the problem is somehow related to the loaded libraries.

Sorry, it appears the 5.1 test builds are being incorrectly bundled with 6.0 libraries. I have notified the package maintainer. You will need to use the previous stable kicad .dmg for now :confused:

I spoke too soon. I pulled up the nightly build on another file and I do see the pause after each action. This is without any libraries, of course.

I then reverted to 5.1.7 after a complete kicad removal, and I now see the slowdown on 5.1.7, whkch I never saw before.

I do notice tha redraws are painfully slow, painting line by line.

No problems with PCBNew. It almost seems as if using unaccelerated graphics, but as far as I can tell, eeschema is using accelerated graphics. In "“Preferences”, the “Modern Toolsset (Accelerated)” option is checked.

Interestingly, the Windows version of KiCad running under Parallels seems to work just fine (except zooming happens in big steps compared with the smooth zooming on Mac).

I haven’t been following the thread. But check the canvas for EESchema (can be set separately from the PCB canvas). The lagging almost sounds like the software rendering of the fallback canvas (F12) instead of the hardware rendering of the accelerated canvas (F11). But I could be wrong…

Also as silly as it sounds, try selecting Fallback and then Accelerated again even if Accelerated is selected.

Followup: This is fixed in 5.1.9.

Fiddling with acceleration on 5.1.8 didn’t do anything. moving back to 5.1.7 retained the issue, against all expectation. I thought it might be an OS issue peculiar to my machine (and maybe it is/was), so I upgraded to MacOS 11.1 Big Sur, but that didn’t change the behavior either.

I have no idea why the 5.1.9 update fixed the problem, but I’m sure glad of it.

It was intentionally fixed :wink:

1 Like

Glad to know I’m not going crazy :slight_smile:

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.