Fritzing too slow

Hi there,
firstly, I am completely new to Fritzing. But now I want to document my several Arduino breadboarded projects by an appropriate tool…which is obviously Fritzing…

I am running an AMD64 computer with lubuntu 17.04 32MB of ram and sufficient processing capacity…this is for sure not the bottleneck of the following issue.

Fritzing responsivenes is that slow, that it can’t be used at all to to design circuits. I tried to install it via apt and manually by downloading/installing the most recent bz2 archive… nothing helps…even the hints given in this forum (enlarge grid size) have not helped.

Can anybody point me in the right direction to get that issue resolved?

Many many thanks in advance!

Go to View/Set Grid Size, and select something courser like 0.025".

Can you give us some information about what is happening? Does it take a long time for the mouse to respond? Do searches take forever? What exactly are the symptoms that you are referring to as slow? Does it become unresponsive for a long time after start up (parts updates make it unresponsive for a few minutes and you must let them complete).

…initially, meaning the first element (ie. ESP32 chip, downloaded from git) let it self move easily. The the GUI gets slower and slower after the seconed element in on the board…wiring almost impossible. It takes the system, said that, endlessly to respond on the next moving acitivity, respectively anoher wiring approach.
I tried the whole thing on an iMac and faced the same…let me know whether I shall catch any logs…please advice for that.
BTW: Parts update takes time…ok…bit I would expect that only for the inital load and not during design with that long delay…

That is correct. It should only be unresponsive on startup until it has updated the parts. After that it should run well.

Since you are seeing the same issue on a MAC as on LDE I doubt it is a hardware/OS issue. But with that said Lubuntu is mostly used on old hardware and is pared back a lot. Also if an IMac is what I think it is then that is also a lower end piece of hardware. Since both of these are likely lower power devices I wonder if they are capable of running Fritzing properly. Have you opened your system monitor and checked how much RAM it is using and how much it is taxing the CPU?

You say you have set the grid size to a large number 0.1 inches and/or turned off the grid so that should not be slowing it down. Be sure to check this again though.

I expect (unless this is a typo) that the 32 megs of ram is the issue. Fritzing runs just as fast as my Windows system on Ubuntu 16.04lts but both my machines have 16 gigabytes of RAM. I expect that your machine is swapping (which will kill performance exactly as you describe) with that little RAM. More ram should clear your problem. Graphics is generally memory intensive, I’d go for at least 2gigs and preferably 4gigs.


Where is the link to the ESP32 on Git.

If the PCB view is grey the grid is ok, it it’s lt blue it’s too fine.

Unrelated to the performance issue, but very relevant: before cutting a board check the PCB hole size on the gerbers.At least one (and possibly more) of the half dozen or so esp32 versions I have fixed up had hole sizes too small. There was a recent thread from someone else that had cut boards and discovered that the hole sizes are too small …


indeed, the amount of RAM was a typo…it’s rather 32Gb…so far many thanks for helping.
Meanwhile I have figured out the following behaviour that is worth to dig deeper:
I had selected Stripboard 1 part with default col/row size of 30/20…after enlargement to col/row 36/21 the system and responsiveness slowed down.
Remarkable has been the look of the stripboard extension because the added cols/rows had not the look of the orginal basic single-sided stripboard…

Turning back to the orginal size…Fritzing worked as charmed…
I had imported the ESP part from git:
ESP32_Miscellany/Fritzing/ESP32 Module Testbed.fzpz

Wish you all the best for the New Year!


There was a post recently about resizing stripboard that might work.

Yep, you appear to have found a bug. On Windows if I set the stripboard size to 36/21 and set board size, the strip board expands incorrectly (the expansion isn’t strips as the original was) and when I drag a Raspberry PI cpu in from core, moving it around slows right down as you describe. Deleting the perf board brings speed back up to normal. One more for my long list of bugs to have a bash at :slight_smile: . Looks to be only the strip board, the perf board (which is what I usually use) appears to work fine.


I provided a workaround in the thread Old_Grey linked to. You just change it from stripboard to perfboard and back again all after making the changes to the hole count and it fixes the display problem. Not sure if it fixes the slow down issue.

Yep, at a quick test it does both fixes the strip board and restores performance, but there is still a bug in there that is worth removing if we can :slight_smile: .