When moving the panel, the graphics card p620 drivers are very slow. The same thing happens on another PC (there is no overload or significant load on the PC)
Application: KiCad x64 on x64
When I select the board and try to move it across the screen, it moves jerkily with pauses of 2 seconds… On a machine with 740m graphics, the behavior is even worse (slower)… At the same time, the loading of hardware is 20-30 percent in total… For example, with the 3D graphics viewer in this project there are no such problems, everything runs fine without delays… It seems that the board editor itself is slowing down, regardless of the hardware
I also noticed that when moving, strange lines remain in place of the board with different directions
I don’t have Intel video cards, both nvidia cards with the latest drivers on two different machines…
Select the board and try to drag it in the board editor screen, also pay attention to how the coordinates change at the bottom (speed)
At the same time, in 3D mode there are no slowdowns or lags, everything works quickly … Very similar to the problem with the Kicad PCB interface I also noticed during testing that the board editor, when moving the board, loads only one processor core
Version 7.0.7
I have an intel i5 9400 with a GT710 nvidia card and all runs nice and smooth here with a 150mm square pcb loaded.
Not sure the last time the drivers were updated either.
My graphics card usage goes to 99% when in 3d viewer but still smooth.
Have you used any plugins that may be causing the slowdown?
This is a small amount for a simple panel… How can this limitation be removed?
And the second small question is why only one core is loaded and not all or part of it?
It is not trivial technically, and there is an easy workaround: don’t do “select all” and then try to move around the board.
This is an example of a thing that is not likely to get fixed anytime soon unless some developer happens to be passionate about it, because it is technically quite a challenging project and also not really that limiting to KiCad users. You just have to avoid selecting a huge number of objects and then moving around.
Multi-threading is used for processing algorithms that can make use of parallelism. It is not generally practical or possible to use multi-threading for the interactive UI rendering part of an application, which is the part you are seeing get slow when you select a lot of objects.
Basically what is going on is that selected objects are rendered differently from unselected objects, in a less efficient way. So, the number of selected objects that can be shown on screen without getting slow is much lower than the number of unselected objects. Fixing this would require some rework of how KiCad’s graphics system works, which may happen some day.
I mostly agree with craftyjon here. I would not call a 130x150mm panel “small” or 9000 items “simple”.
But I do agree KiCad acts a bit sluggish here.
Something I do not agree with is:
A very simple and quick solution is to simply abort the rendering as soon as a further move is detected.
If for example KiCad draws the eye catching and important parts first ( Copper, footprints, Edge.Cuts) and things like via’s, ratsnest, fab layers and such last. then the moving performance can easily be done at whatever framerate you wish. If you want 20 frames per second, then just check whether the mouse moved after 50ms of rendering and start redrawing at the new location if it did move. I once did this on a 80386sx, and was the difference between completely unusable (20seconds for a frame) to “quick and snappy”. I think I checked for mouse movent events instead of a time.
And for me, moving these 9130 items is also not very quick, but still a lot faster then for m852. There is a noticeable delay for the first move, but after that it works quite acceptable.
My current PC is a Ryzen 5600G, which is reasonably modern, but nothing spectacular. I recently noticed this processor costs EUR130 now. If you want to consider buying a new PC for CAD stuff, then single thread performance is (unfortunately) likely more important then the number of cores. I like the cpubenchmark.net website for it’s no-nonsense easy performance comparisons (and price to performance comparisons) of nearly all available PC processors.
This is the kind of thing that sounds simple and quick to someone who does not understand how KiCad is implemented technically. I mean no offense here.
I know nothing of KiCad’s internals. After some brain damage I can’t work on anything with that sort of complexity, and doing some user support and bug reports is the best I can do for KiCad. When I did that way back on my 80386sx for a DOS program, it was just a handful of lines of code. It was just an abort of rendering for the screen. But in the last 30 years a lot has changed in the computer and software technology.
There is no trivial way for KiCad to receive a mouse event while in the middle of rendering at the moment. Of course one could be added (probably) but it is not a simple change.
Understandable. Probably legacy stuff I guess. In an Ideal world applications would be built multi threaded from the very start, and receiving and dispatching mouse events would be done by a different thread, and each layer of the PCB (or objects like via’s) could be rendered by another thread. But such changes probably require a lot of refactoring, and if you ask me. KiCad is already doing a wonderful job with the little development resources they have available.
I would not call this really slow for 9000 components.
One thing I notice is that moving the board causes some network activity. If this is the crash telemetry, its latency might be slowing things
