Earlier this morning I did a:
git clone https://github.com/Architeuthis-Flux/Jumperless.git
It seems to be a quite nice project and a lot of effort has been put in it, but I can’t manage to fill the zones on the PCB. When I depress b (Edit: In revision 3 of the PCB), the fan on my PC spins up and starts humming, while one of the 12 threads on my Ryzen 5600G pushes CPU up to a short bump around 20%, but after that it is a continuous 8.5% or so for two full minutes. After those two minutes, the fan gets quiet again, but the zones are not filled (By default they are also set to cross-hatch, but changing that does not make a noticeable difference).
In total I have 2 issues left concerning the working of KiCad here:
- Zone fill takes two whole minutes while under utilizing multithreading.
- [solved] The zones were (not are) not filled afterwards. (Silly me, hit the button qu1ck showed).
- You can press the Cancel button, but it keeps on going for the two minutes.
[Edit:] So it’s not a bug, they do fill but the performance issue remains.
Both Rev. 2 and Rev. 3 take about 2 minutes, while Rev. 1 takes over 4 minutes to fill.
Anyone else care to give this project a zone fill treatment and report whether it works?
If I can get confirmation of either a performance issue or bug, then I will file a bug report on gitlab. This looks like a good test case.
Application: KiCad PCB Editor x86_64 on x86_64
Version: 7.0.7-7.0.7~ubuntu20.04.1, release build
libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3
Platform: Linux Mint 20.3, 64 bit, Little endian, wxGTK, xfce, x11
Date: Aug 13 2023 23:14:53
wxWidgets: 3.2.1 (wchar_t,wx containers) GTK+ 3.24
Compiler: GCC 9.4.0 with C++ ABI 1013
Took a good 2 minutes for me on 12 core 3900x to fill but it worked fine. I’m still on 7.0.5.
Note, I had to switch zone render mode to filled.
Just to be sure, this is: edit the properties of a zone and then Fill Type / Solid Fill
(Or can this be overruled with some global setting?)
I first tried this with Rev. 3 of the board. when I do it with Rev. 2 the zone filling does work, even with the cross hatch, but it also takes 2 minutes.
No I meant the top button here
I tried rev 3 of the board.
@ qu1ck, oops, silly me, forgot about that button, it works for me now too, updated my opening post.
And the plot thickens…
As a test, I deleted all the zones, and divided the PCB into 4 (not overlapping) zones by snapping corner points of 4 zones together. All 4 zones are set to In1.Cu, In2.Cu and B.Cu layers, and the zones now fill in 15s. (In retrospect, there was no big zone on F.Cu)
Adding the F.Cu layer and time increases again to two minutes.
[A little bit later…]
Examining the F.Cu shows “Kevin Santo Cappuccio”. If that object is removed, zone filling on the freshly loaded Rev. 3 board is back to 5 seconds.
Oh yeah, sorry I didn’t warn you about that.
It took about 5 minutes to fill the zones for me too, and it happens when the fills go up against the imported polygons like that. No idea what causes that.
Like, I get that it’s a lot of math and a somewhat uncommon thing to do, but yeah it takes a looooong time. I’m guessing it’s some semi-bug in KiCad where it’s doing something like checking all the borders of all the zones for each point or something like that.
Feel free to delete my name on the board, it’s just a bit of aesthetic flair anyway.
And if you have any more questions about Jumperless, I’d be happy to answer them.
That is not my intention at all.
My only concern is whether this performance issue is worth filing a bug report, and your project is a sensible test case in that regard.
I am more likely to delete (almost) everything exept that string to simplify the testcase.
Just in case you do file a bug report, here’s what I did. That was text rasterized and skewed in Photoshop, then “Trace Bitmapped” in Inkscape and then imported with Import > Graphics. I also scaled it down in the Import Graphics window (to 0.42 iirc) in case that’s relevant.
Let me know if you need any more info or files to reproduce it.
Rasterization and then re-vectorization likely generated a whole lot of vertices. It is probably not so much a bug for kicad to be slow on it, just an unoptimized corner case. It should be possible to simplify such unnecessarily complex polygons and reduce number of vertices when calculating zones based on clearance settings.
Worth reporting with a simple test case either way.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.