Move/Drag slow redraw (in schematic editor)

Hey there!

When make a box selection and drag or move the selected components and wires the redrawing of the selected group is very slow. I know that when you move something you have to delete the objects at the old location and redraw every single line at the new position but I don’t see the point why it takes almost 2 seconds to do this task. In the selection there are 8 output stages with 14 components (FET, R, D, C) and approx. 50 wire segments per stage.

For the record, my KiCad has version 4.0.6, release build and it is running on 64bit Windows 10.
Lenovo thinkPad P50, i7-6700HQ, 16GB RAM, Intel HD graphics 530, Nvidia Quadro M1000M.
My standard desktop configuration is a ViewSonic 4k display as main screen and the laptop screen is second. But I see no or nearly no performance difference when i use the full HD display of the laptop solely.

I hope somebody has some hints! Thank you!
Greetings Norbert

Graphic speed has been a shortcoming of every CAD/CAE tool I have ever used. Somebody has probably measured the benchmarks but I suspect KiCAD is comparable to the others; faster at some operations and slower at others. I don’t recall the lag being quite as bad as you report (2 seconds). Your hardware is more capable than mine so perhaps there is some software running in the background to slow things down. (I run Win7/64 with a minimal set of “features” activated.)

When you move a selected block the dialog box gives you the option to “Draw Selected Items While Moving”. The implication is that you can use the visual image as feedback to guide the “Move” operation. As you have seen, this isn’t truly practical. I have trained myself to think-through a “Move” operation before I actually do it. Then I do my best estimate of the whole mouse movement, wait for the redraw, then make minor corrections with the mouse. It takes a little practice to operate the mouse “open loop” rather than “feedback guided” but the result (for me, at least) is improved productivity.

Another feature I use a lot is the “Move Exactly” tool. Rather than grabbing a selection and dragging it around until it “looks right”, I figure out exactly where I want it to land and calculate its displacement from the present position. (Yes, there is a pad of paper, filled with unfathomable numbers and very crude sketches, sitting on my desk.) The “move Exactly” tool lets me park a selected block exactly where I want it. (OK, I still get the sense of the Y-axis wrong about once every 5 or 6 operations. On the other hand, it’s the ONLY way to give an angular rotation to a component, other than 90 degrees.)

Dale

I gave up trying to hard.

My good friend was in the Army and had to line up some fire control system with 2 knobs for x and y. He was outside and the knob mover was inside.

He knew which knob was which knob and which way to turn each knob to get the desired results; of course this was almost never the case for the person that was assigned to turn the knobs.

His solution was to tell the inside person to turn ANY knob ANY direction. He could then see if the knob turned was the X or Y knob; without having to ask. He could then say, turn it N amount more, or turn it the other way. Then, say, turn the other knob ANY way. Then repeat the above.
Moral of the story:

Enter the number you think it should be. If it moves the wrong way, hit Cntrl+Z and change the sign the next time on the exact move.

I’m simply mentally prepared that X and Y directions learned in college has been fundamentally programmed into my brain (and I have not drank enough beer to kill those brain cells where that data is stored).

2 Likes

Well, I tried it, and I did not like it >>> Windoze 10.

You are on a laptop.

Eeschema does not take advantage of any video acceleration - to MY understanding.

My suggestion is to either learn to wait, or to try to think a few moves ahead and move as few block portions as possible.

Neither option is optimal.

A powerful machine, but a hybrid graphics system, which does seem to sometimes cause OpenGL problems.
Have you tries the test in this thread TESTERS wanted with broken/weird OpenGL
Very slow screen draw sounds like the consequence of OpenGL software emulation

Thank you very much for all the replies so far!
There is an option in the nvidia control panel to force the “graphics card selector” to use nvidia card and not the Intel HD graphics card for certain programms. There I selected KiCad for the nvidia card but I experienced no performance gain.
I tried the test, posted by @davidsrsb
Here is the output:

INFO: Instantiated GL window
INFO: Found OpenGL version 4.5
INFO: Successfully called OPENGL_GAL::BeginDrawing
PASS

not very helpful, i was hoping for an error ;)!

I’m confused, are we talking about eeschema or pcbnew? eeschema doesn’t use OpenGL at all does it?

Redraw in eeschema has always been slow, and especially with a lot of items in the selection. KiCad uses wxWidgets for the GUI, which is great for cross-platform but lousy for performance. You can easily see the difference in pcbnew in legacy vs OpenGL canvas, with the OpenGL canvas, you get super-fast redraw, in legacy mode the graphics crawls across the screen like a snail.

Hopefully, eeschema will also use the OpenGL canvas in the future.

1 Like

We are talking about the slow behavior of eeschema.

For the case it is fact that eeschema does not use any hardware acceleration, I also hope that the OpenGL canvas gets implemented in eeschema.

Ok, I thought so. Some people have a habit of not reading the topic properly and then going off on confusing tangents.

I don’t like to brag but I have a water cooled GFX card, if any program runs slow on that it’s not a hardware issue :smile: