Slow zooming and panning when board is selected

[Fabián Inostroza]

Open the demo project kit-dev-coldfire-xilinx and launch Pcbnew, select the board and zoom and/or pan, it is slow. The same actions are fast when the board is unselected.

I'm using the modern toolset (accelerated).

Application: kicad
Version: (6.0.0-rc1-dev-291-g78ab5c3f0), debug build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.60.0 GnuTLS/3.5.19 zlib/1.2.11 libidn2/2.0.4 libpsl/0.20.2 (+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.32.0 librtmp/2.3
Platform: Linux 4.17.0-1-amd64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.62.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.60.0
    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=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=OFF

[Hildo Guillardi Júnior (hildogjr)]

Confirmed on Linux 16.04 since release of 2018-07-27 (I didn't remember before).
Also this happens when appended new board (summarizing, every that a large number of elements are selected).

[Seth Hillbrand (sethh)]

Is this still an issue with current nightlies?

[Wayne Stambaugh (stambaughw)]

The zooming does seem to be slower in modern canvas when the entire board is selected. As soon as I deselect everything, the zooming is faster. This is on my Debian testing build.

[Fabián Inostroza (fabianinostroza)]

I've checked the current master in release build and it works fine.
The slowness is still noticeable in a debug build.

[Jeff Young (jeyjey)]

Interesting. Anyone know why this would be slower in debug? (Are we spitting out a bunch of log statements or something?)

[Fabián Inostroza (fabianinostroza)]

I don't really know, at least I see no logs in console output.
Initially I though some code was better optimized in release build.

[Maciej Suminski (orsonmmz)]

I would point at optimization and wxASSERTs. There is also a bunch of wxTRACE, but I *hope* they do not decrease performance until enabled.

[Jeff Young (jeyjey)]

I'm not sure it has anything to do with debug/release. It's much slower because LAYER_SELECT_OVERLAY is not cached (so we draw it every time).

Is there a reason TARGET_OVERLAY and TARGET_CACHED can't both be cached? (Perhaps we'd need to then change the name of TARGET_CACHED....)

[Maciej Suminski (orsonmmz)]

In #5 there was a question regarding potential reasons of different performance in debug and build releases. You are right regarding the primary cause, anything rendered on TARGET_OVERLAY redraws everything.

TARGET_CACHED is for long-term storage and uses video memory, which saves a lot of bandwidth. Normally one modifies just a few items at once, so the remaining data may sit in the viedo memory untouched and does not need to be uploaded every frame.

On the other hand, TARGET_OVERLAY stores vertices that are displayed just for a few frames. There is no benefit in keeping them in cache, as they still need to be recalculated and uploaded to the video memory for each frame. It is possible that changing the storage method would decrease the performance due to fragmentation.

[Jeff Young (jeyjey)]

Does the video card keep the last frame, or _only_ cached vertices?

If it keeps the last frame, can we transpose it and render only the newly exposed regions?

If not, should we close this as "Won't Fix"?

[Maciej Suminski (orsonmmz)]

It keeps both - each target is rendered to a separate framebuffer and then compositor combines the their contents. If a target has not been touched, then it is not refreshed but displayed using the framebuffer contents from the previous frame.

I have already considered the transposition idea, and I am sure it is feasible and would give a performance boost. I simply never had the time to implement it.

[Jeff Young (jeyjey)]

Cool; I'll leave this open then. (I might even try to get my head around OpenGL at some point and give it a whack.)

[KiCad Janitor (kicad-janitor)]

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