Highlight cross-probe before click-handling

Bug #1774179 reported by Janis Skujenieks on 2018-05-30
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Seth Hillbrand

Bug Description

When I select component in Eeschema it takes a noticeable time before the according footprint gets selected/highlighted in Pcbnew. It feels about 0.5 seconds or more for me. My PCB is quite simple. I wouldn't report this, but I remember it previously was practically instant. Previously I was using 8c78bd5fd87e3db84c0ff01291c7b43dc976bb5c commit with some personal changes.

Current version:
Application: kicad
Version: (5.0.0-rc2-35-gda6600525), debug build
    wxWidgets 3.0.4
    libcurl/7.59.0 OpenSSL/1.1.0h zlib/1.2.11 libidn2/2.0.4 libpsl/0.20.1 (+libidn2/2.0.4) nghttp2/1.31.1
Platform: Linux 4.16.2-2-ARCH 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.66.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.59.0
    Compiler: GCC 7.3.1 with C++ ABI 1011

Build settings:

Seth Hillbrand (sethh) wrote :

Hi Janis-

I note that you are running a debug build. Many features are slower with the debug build than the release build although I'm not certain that this is one of them. Can you test with a release build and see if the update speed is what you remember?

Changed in kicad:
status: New → Incomplete

Yes, I'll test release.

I've tested with release build and it looks to be the same speed as in debug.

Interesting observation! Reverse operation, that is, click on component in Pcbnew and centering on it in Eeschema is very fast (instant).

One more thing I observe. In Eeschema if I click on component pin and get clarify selection dialog and click component from this dialog, Pcbnew highlights appropriate component instantly. This works for pads also. Only thing is that clarify select dialog shows after some delay ~0.5s for me. So It seems the delay is somehow tied to Eeschema.

Seth Hillbrand (sethh) wrote :

This is related to the disambiguation menu in eeschema. We insert a pause between a click and the click action in order to allow for double-click handling before the disambiguation menu pops up. Otherwise the first click shows the menu and then swallows the second click.

Changed in kicad:
status: Incomplete → Won't Fix

Do you or anybody reading this know if V6 changes to Eeschema will influence this? Will this functionality be reimplemented?

Seth Hillbrand (sethh) wrote :

The GAL changes to eeschema won't affect this.

However, we could look at ways to opportunistically cross-probe where we select the "most-likely" option for highlighting before we process the full click/double-click handling.

summary: - Selected component highlight speed (Eeschema->Pcbnew)
+ Highlight cross-probe before click-handling
Changed in kicad:
assignee: nobody → Seth Hillbrand (sethh)
importance: Undecided → Wishlist
milestone: none → 6.0.0-rc1
status: Won't Fix → Triaged
Seth Hillbrand (sethh) on 2018-06-23
Changed in kicad:
milestone: 6.0.0-rc1 → 5.1.0
Jeff Young (jeyjey) wrote :

I implemented some heuristics for selection disambiguation. Since schematics are meant to be human-readable, we don't have all the overlap and coverage issues that we did in Pcbnew.

While the menu will probably still come up in the Symbol Editor (due to overlapping pins, etc.), I think it will be rare enough in eeschema that I got rid of the timer there.

And since we don't cross-probe from the Symbol Editor, this bug no longer exists. ;)

Changed in kicad:
status: Triaged → In Progress
Jeff Young (jeyjey) wrote :

@Seth, I can't set it to Fix Committed because it's in Tom's GAL branch (which isn't yet on master). Should I leave it for you to close when the time comes, or do you want me to re-assign it?

Seth Hillbrand (sethh) wrote :

@Jeff- I don't think selection disambiguation affects this. It's more of a single-click vs. double-click disambiguation. But maybe I'm thinking about this too linearly and you've got a better work-around.

Jeff Young (jeyjey) wrote :

Without the selection disambiguation issue, double-click should always be an "extension" to single-click so that it's safe to go ahead and process the single-click. (The platform will then deliver a double-cick event on the next click if it was in the double-click time period.)

Wayne Stambaugh (stambaughw) wrote :

Version 5.1 is in feature freeze. Moving to 6.0.0 milestone.

Changed in kicad:
milestone: 5.1.0 → 6.0.0-rc1
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers