Pcbnew move command is choppy

[Igor]

Hi,

There seems to be a a problem in the windows version of Pcbnew where moving a component is very choppy when using the modern toolset (either accelerted or Fallback. Routing or panning the view is smooth as expected.

The legacy toolset is a little smoother but the component flashes as it is moved.

When I run the application in Compatibility mode for Windows 7, the move command is smooth but the route command is really slow.

I've tried both 64 and 32 bit builds.

A screen capture of the behavior is shown here:
https://streamable.com/eax4e

--------------------------------

Application: kicad
Version: (5.0.1)-3, release build
Libraries:
    wxWidgets 3.0.3
    libcurl/7.54.1 OpenSSL/1.0.2l zlib/1.2.11 libssh2/1.8.0 nghttp2/1.23.1 librtmp/2.3
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
    wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.60.0
    OpenCASCADE Community Edition: 6.8.0
    Curl: 7.54.1
    Compiler: GCC 7.1.0 with C++ ABI 1011

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

[Seth Hillbrand (sethh)]

@Igor-

Can you try the 5.0.2-dev build at http://downloads.kicad-pcb.org/windows/testing/5.0/

[Igor (gregoryfitz)]

Thanks for the quick build. I installed the version you linked. Behavior is about the same.

Version info below:
-------
Application: kicad
Version: (5.0.1-29-g839ade2c0), release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.61.1 OpenSSL/1.1.1 (WinSSL) zlib/1.2.11 brotli/1.0.6 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) nghttp2/1.34.0
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.68.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.61.1
    Compiler: GCC 8.2.0 with C++ ABI 1013

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

[Seth Hillbrand (sethh)]

Can you post information about your graphics card? Are the drivers up to date?

[Igor (gregoryfitz)]

Sure,
The display graphics card info is below. I noticed that you mentioned 5.0.2-dev. Did I install the right release? The release info in my install says 5.0.1-39.

[Display]
Operating System: Windows 10 Pro, 64-bit
DirectX version: 12.0
GPU processor: GeForce GTX 970
Driver version: 416.34
Driver Type: Standard
Direct3D API version: 12
Direct3D feature level: 12_1
CUDA Cores: 1664
Core clock: 1164 MHz
Memory data rate: 7010 MHz
Memory interface: 256-bit
Memory bandwidth: 224.32 GB/s
Total available graphics memory: 11771 MB
Dedicated video memory: 4096 MB GDDR5
System video memory: 0 MB
Shared system memory: 7675 MB
Video BIOS version: 84.04.36.00.70
IRQ: Not used
Bus: PCI Express x16 Gen2
Device Id: 10DE 13C2 29743842
Part Number: G401 0010

[Maciej Suminski (orsonmmz)]

Seth,

Are you able to reproduce the problem? Is it Windows specific? GTX970 is so powerful that I would not expect any performance issues there.

[Seth Hillbrand (sethh)]

@Igor-

Can you share the board you show in the video? Also, can you try with the ratsnest disabled?

Orson, I don't suspect the video card as his pan is smooth, so the re-draw doesn't seem to slow it down. I can't reproduce this on my machine or the windows virtual box I use, so I'm thinking there may be something specific in the board.

[Igor (gregoryfitz)]

Hi Seth,

I've attached the PCB file.

I tried a few more things:

- Moving text, unconnected vias or layer alignment targets is also choppy but less so.
- Turning off the ratsnest did not help (while moving a component the components rats still show, not sure how to turn off)
- The footprint editor has the same issue when moving pads.
- Changing the grid has no effect.

I will try running it in a VM during the weekend. It may be something system specific.

[Seth Hillbrand (sethh)]

Thanks. Doesn't seem to be board-specific. At least there is no lag that I can detect on Linux. I'll try in my VM tomorrow.

[Igor (gregoryfitz)]

Tried in a windows 10 VM (mac os host). Move was smooth but crashed shortly after, probably due to Bug #1798460.

I think the choppy move may be system specific.

[Dylan Bartlett (dylanbrtlett)]

I am the author of Bug #1807610 and am also experiencing this behaviour. I am running a fairly powerful PC, with an i5-4430 and a GTX 1080 Graphics card so I am expecting system performance to not be a factor here.

Presumably this is something system specific as Igor reported but is there a commonality between his issue and mine?

[Seth Hillbrand (sethh)]

I suspect that this is an issue with your threading libraries.

We supply an up to date version of winpthreads that is meant to be faster when creating/destroying threads than the previous version. However, if you have other open-source software installed, it is possible that their libraries are being loaded instead of the versions distributed with KiCad.

You might try uninstalling any other open source software, including KiCad and then re-installing KiCad 5.0.2.

[Igor (gregoryfitz)]

Good insight.

Is there a way to force the kicad 5.0.2 install to overwrite old libs?

[Seth Hillbrand (sethh)]

I don't think so. At least not in a way that will ensure other libraries are not loaded as I believe that this depends on your system settings (I could be mistaken in this)

[Jeff Young (jeyjey)]

Can we statically link our version of winpthreads into the build?

[Nick Østergaard (nickoe)]

Maybe it is possible to use process explorer to check which dll it uses?

https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer

[drojf (drojfjord)]

<I'm a users who raised one of the duplicate bug reports>

I tried using process-explorer, and it seems to be using the actual Kicad DLL (see attached image).

To make sure it was correct, I renamed the Kicad winpthread DLL and Kicad won't open anymore (it comes up with missing DLL error).

Let me know if there's anything else you want to try.

Note to others using process explorer - you have to go view->Show Lower Plane to view the DLLs.

[Nick Østergaard (nickoe)]

But I thunk I saw a bugreport where the user was on linux and he had two windows of pcbnew open at the same time. Only the one window showed laggy move of the footprint.

[Igor (gregoryfitz)]

I recently formatted and re-installed Windows 10 and Kicad 5.1. I am still getting the same behavior.
Maybe it's a system/driver issue?

[Nick Østergaard (nickoe)]

Ok, I found the video I was talking about in #17.

It is https://bugs.launchpad.net/kicad/+bug/1821561/+attachment/5249130/+files/QQ%E7%9F%AD%E8%A7%86%E9%A2%9120190325121415.mp4

It is also on windows, but it shows that it works and not works on the same machine at the same time! :O

[Michael Kavanagh (michaelkavanagh)]

@Nick, the video is comparing two different versions of KiCad (5.0.0-rc2 and 5.1.0 IIRC, check the original bug report)

[Nick Østergaard (nickoe)]

Ahh ok, I missed that. Disregard the comments #19 and #17.

[Seth Hillbrand (sethh)]

@gregoryfitz- Can you try with the 5.1.5RC1 nightly build from https://kicad-downloads.s3.cern.ch/windows/testing/5.1/kicad-5.1-jenkins-450-x86_64.exe ? We have recently updated the packaging versions and would like to know if this affects the threading issues.

[drojf (drojfjord)]

Previously I was on "Version: (5.1.4)-1, release build", and I just tried the above "Version: (5.1.5-rc1-4-g167d408b5)-1, release build" - there doesn't seem to be any change in behavior (it's still choppy).

I uninstalled the old version first, then installed the new version, if that makes any difference.
(My pc details are in https://bugs.launchpad.net/kicad/+bug/1822404)

[Igor (gregoryfitz)]

There is no improvement for me as well. I had some time to look closer at it.

1. Process Explorer shows "C:\Program Files\KiCad\bin\libwinpthread-1.dll"

2. When moving a part footprint, kicad usage goes from 0% cpu to ~10%. When i stop moving, it drops to ~0% (see attached)

3. When moving a footprint, the page fault delta peaks around >3000. Drops to 0 when not moving.

4. The main thread (kicad.exe+0x14c) CPU increases in the process explorer thread list. Additional threads don't seem to be spawned. Other threads CPU usage remains ~0

It's kinda hard to take a screenshot of some of the performance counters while moving the mouse. I can try to post a video if necessary.

Is there other tools that I can use to get more debug data?

https://imgur.com/zX2sxUa
https://imgur.com/wr55HzP
https://imgur.com/w2mle8K

Regards.
----

Application: Pcbnew
Version: (5.1.5-rc1-4-g167d408b5)-1, release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.66.0 OpenSSL/1.1.1d (Schannel) zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.1.1) nghttp2/1.39.2
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.71.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.66.0
    Compiler: GCC 9.2.0 with C++ ABI 1013

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=OFF
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

[Seth Hillbrand (sethh)]

winpthreads again. Ugh.

Incidentally, Mozilla had a similar issue. For a number of years they were also excising std::thread from their codebase because of this windows issue[1]. But then they shifted to clang for all their builds, upstreamed some code and resolved the issues they had[2] sufficiently to be useful.

We might consider testing a clang-based build.

Incidentally, clang also generates the correct AVX alignment, which would allow the newer Python builds.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1349912
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1456575

[Wayne Stambaugh (stambaughw)]

Interesting. I just thought I wasn't seeing this on my windows box
because it's a pretty fast system but now that I think about it, my
windows builds are using clang due to a gcc build issue with one of the
dependency libraries. I think this gcc dependency build issue has since
been fixed but my build config is still using clang. Maybe we should
convert our windows builds over to clang instead of gcc to see if that
resolves this issue. Good catch Seth.

 - Wayne

On 11/7/19 11:15 PM, Seth Hillbrand wrote:
> winpthreads again. Ugh.
>
> Incidentally, Mozilla had a similar issue. For a number of years they
> were also excising std::thread from their codebase because of this
> windows issue[1]. But then they shifted to clang for all their builds,
> upstreamed some code and resolved the issues they had[2] sufficiently to
> be useful.
>
> We might consider testing a clang-based build.
>
> Incidentally, clang also generates the correct AVX alignment, which
> would allow the newer Python builds.
>
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1349912
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1456575
>
> ** Bug watch added: Mozilla Bugzilla #1349912
> https://bugzilla.mozilla.org/show_bug.cgi?id=1349912
>
> ** Bug watch added: Mozilla Bugzilla #1456575
> https://bugzilla.mozilla.org/show_bug.cgi?id=1456575
>

[Igor (gregoryfitz)]

Can someone provide a clang build? I’d like to see if it improves.

[Rogier Lodewijks (rogier-f)]

I'm experiencing same behavior in several stable versions and also in a recent nightly (5.99.0-393-gd4cea0f2b). Also running Windows 10 x64, with an i7-2600 3.4GHz CPU and middle of the road GFX card (Radeon HD 6700M). Waited some time for this to disappear (~ 1 year), expected it to be a temporary bug, but the problem seems pretty persistent.

When I select _one_ footprint in Pcbnew, moving it is very choppy (and very annoying), zooming and panning the whole board is really quick and smooth with the accelerated toolset.

The interesting behavior i'm experiencing (and what might be a pointer to the underlying problem) is thet when I select _multiple_ footprints, the choppy-ness disappears. Moving multiple parts at the same time works as expected.

Hope this helps!

Ps. Happy to try the Clang build!

Cheers!
Rogier.

[Seth Hillbrand (sethh)]

@Nick- What do we need to generate a test clang build?

[Rogier Lodewijks (rogier-f)]

Possibly (not) related, after working on KiCAD stable for a while switched to nightly (5.99.0-393-gd4cea0f2b) yesterday.

This nightly has the same (or similar) choppyness on my PC when moving symbols in _Eeschema_ as it has in Pcbnew. The stable version does not seem to have this problem.

- Rogier.

[Nick Østergaard (nickoe)]

@Seth, sorry, I forgot this. It should be possible, it looks like there is a clang toolchain for mingw in the msys2 repos. But last time I updated the build environment my patch job stopped working, and I am not quite sure why. But probably a PEBCAK because the nigthly builds using makepkg works fine.

[Wayne Stambaugh (stambaughw)]

I finally found some time to test this again and I do see the choppy move behavior with 5.1.5 downloaded from the KiCad website. The downloaded version of the KiCad windows installer was build with gcc 9.2.0. I tried to update my clang builds but apparently the latest version of clang (both 32 and 64 bit builds) crashes attempting to build libcontext.cpp so I cannot go back and confirm the clang behavior without doing a downgrade of clang. This most likely explain why @Nick saw a build failure. If someone else has an older version of clang (the latest is 9.0.0) and has the time to confirm this behavior, I would appreciate it.

[Seth Hillbrand (sethh)]

@Wayne-

What is the clang build error? I have a test branch that provides naked function signatures in libcontext that may resolve this. It was required for me to utilize sanitizer a while back but I haven't fully tested it. If the same issue is blocking clang, I could send the patch around for larger review.

[Wayne Stambaugh (stambaughw)]

@Seth, it's not a build error. Clang actually crashes. Here is the output of the crash:

[ 27%] Building CXX object common/CMakeFiles/common.dir/system/libcontext.cpp.obj
Stack dump:
0. Program arguments: E:\msys64\mingw64\bin\clang++.exe -cc1 -triple x86_64-w64-windows-gnu -emit-obj -disable-free -disable-llvm-verifier -discard-value-names -main-file-name libcontext.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -momit-leaf-frame-pointer -coverage-notes-file E:\build\mingw64\kicad\trunk-release-clang\common\CMakeFiles/common.dir/system/libcontext.cpp.gcno -resource-dir E:\msys64\mingw64\lib\clang\9.0.0 -isystem E:/msys64/mingw64/lib/wx/include/msw-unicode-3.0 -isystem E:/msys64/mingw64/include/wx-3.0 -D GLEW_STATIC -D GLM_FORCE_CTOR_INIT -D HAVE_STDINT_H -D KICAD_CONFIG_DIR=kicad -D KICAD_SCRIPTING -D KICAD_SCRIPTING_ACTION_MENU -D KICAD_SCRIPTING_MODULES -D KICAD_SCRIPTING_WXPYTHON -D KICAD_SPICE -D KICAD_USE_OCE -D UNICODE -D WXUSINGDLL -D WX_COMPATIBILITY -D _FILE_OFFSET_BITS=64 -D _UNICODE -D _USE_MATH_DEFINES -D __USE_MINGW_ANSI_STDIO=1 -D __WXMSW__ -I E:/msys64/home/Wayne/src/kicad-lp-clone/include -I E:/msys64/home/Wayne/src/kicad-lp-clone/common/ -I E:/msys64/home/Wayne/src/kicad-lp-clone/common/dialogs -I E:/msys64/home/Wayne/src/kicad-lp-clone/common/widgets -I E:/msys64/home/Wayne/src/kicad-lp-clone/common/dialog_about -I E:/msys64/mingw64/include/cairo -I E:/msys64/mingw64/include/pixman-1 -I E:/msys64/home/Wayne/src/kicad-lp-clone/common/../3d-viewer -I E:/msys64/home/Wayne/src/kicad-lp-clone/common/../pcbnew -I E:/build/mingw64/kicad/trunk-release-clang -I E:/msys64/mingw64/include/python2.7 -I E:/msys64/home/Wayne/src/kicad-lp-clone/scripting -I E:/msys64/mingw64/cmake/../include/oce -I E:/build/mingw64/kicad/trunk-release-clang/common -I E:/msys64/home/Wayne/src/kicad-lp-clone/bitmaps_png/include -I E:/msys64/home/Wayne/src/kicad-lp-clone/polygon/include -D NDEBUG -internal-isystem E:\msys64\mingw64\x86_64-w64-mingw32\include\c++ -internal-isystem E:\msys64\mingw64\x86_64-w64-mingw32\include\c++\x86_64-w64-mingw32 -internal-isystem E:\msys64\mingw64\x86_64-w64-mingw32\include\c++\backward -internal-isystem E:\msys64\mingw64\x86_64-w64-mingw32\include\c++\9.2.0 -internal-isystem E:\msys64\mingw64\x86_64-w64-mingw32\include\c++\9.2.0\x86_64-w64-mingw32 -internal-isystem E:\msys64\mingw64\x86_64-w64-mingw32\include\c++\9.2.0\backward -internal-isystem E:\msys64\mingw64\include\c++\9.2.0 -internal-isystem E:\msys64\mingw64\include\c++\9.2.0\x86_64-w64-mingw32 -internal-isystem E:\msys64\mingw64\include\c++\9.2.0\backward -internal-isystem E:\msys64\mingw64\lib\gcc\x86_64-w64-mingw32\9.2.0\include\c++ -internal-isystem E:\msys64\mingw64\lib\gcc\x86_64-w64-mingw32\9.2.0\include\c++\x86_64-w64-mingw32 -internal-isystem E:\msys64\mingw64\lib\gcc\x86_64-w64-mingw32\9.2.0\include\c++\backward -internal-isystem E:\msys64\mingw64\lib\clang\9.0.0\include -internal-isystem E:\msys64\mingw64\x86_64-w64-mingw32/sys-root/mingw/include -internal-isystem E:\msys64\mingw64\x86_64-w64-mingw32\include -in...

[Nick Østergaard (nickoe)]

@Wayne, what are your cmake args to make it use clang? I never tried it on my windows environment.

[Wayne Stambaugh (stambaughw)]

@Nick, all you need to do is set the environment variable CC=clang and CXX=clang++ and run cmake to create the build configuration as you normally would. CMake picks up clang as the compiler and sets up the build environment accordingly. I'm guessing you could also set CMAKE_C_COMPILER and CMAKE_CXX_COMPILER as well but I never tried that.

[Wayne Stambaugh (stambaughw)]

Grrrrrr! I just tried a 64 bit build with the clang 8.0.1-3 package and I'm getting the same error. Now I'm beginning to wonder how this ever built on clang. Did we change libcontext.cpp recently?

[Wayne Stambaugh (stambaughw)]

Just to add insult to injury, clang 7.0.1-1 wont even run so I'm at the end of my rope here.

[jean-pierre charras (jp-charras)]

I tried to build Kicad with clang on W7 32 bits.

I just had to fix a few compil warnings, and not found symbols.
Attached, my changes in CMakelist.txt.
Some are perhaps specific to a 32 bits build.
option "-femulated-tls" avoid not found symbols.
others are more to avoid a lot of warnings during compilation.

Of course I added this option in cmake invocation (and only that):
-DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++

My clang version is 9.0.0

[Tomasz Wlostowski (twlostow)]

Concerning the compiler crash, here's a patch that enables libcontext's winfiber API also for MSYS/MINGW (not tested as I don't have a Windows setup with MSYS here).

[KiCad Janitor (kicad-janitor)]

KiCad bug tracker has moved to Gitlab. This report is now available here: https://gitlab.com/kicad/code/kicad/-/issues/1865