I noticed that the Live mode of the Select Objects in Human (@andheum ) has a new display glitch when activated and selected objects are dragged around. This appeared some time in Rhino 6, not sure which service release.
I know his component was written a long time ago, so I wrote a component myself to see if I could debug. I tried removing the objects themselves from the outputs to see if it had to do with previewing referenced geometry in the component.
Unfortunately, I’m having the same issue (see attached). De-activating the component returns previews to normal.
Is there a bug or is there some kind of preview override I need to implement to avoid this? It causes a fairly significant UX issue for my tools and I really need live object selection.
Final note, I notice that the ghosted glitch is proportional to the distance moved (a ghosted geometry appears exactly 2X the distance of the move itself and then snaps back, sometimes leaving a ghost in rendered mode).
If I had to hazard a guess, what I think is happening is that there’s a process by which a temporary transform (from in-command preview) gets applied to an object and then officially committed to the object. Somehow the temporary transform is getting applied for a split second to the object after it is committed to the object… hence the doubling. You can see this even if you scale the object; the object will scale double for a split second before the correct change takes effect. The involvement of Human is simply that it inserts a slow action somewhere in this temporary-to-permanent transform process (all those nasty event listeners attached to the select events). I suspect this slow action makes the effect visible when otherwise it would be unnoticeable.
I was thinking something similar but wasn’t quite able to articulate it like you have here Andrew – as a workround, I’m wondering if using a ScheduleSolution within the event listener might allow the temporary transform to finish its business before the “slow action” interferes with it. Might try it in a couple hours…
Solved it using a ScheduleSolution approach. Incidentally, moving objects causes a massive number of events. Window selecting is great, it’s all bundled up in one event. When you have 5 objects selected and you move them, you trigger 5 Selected and 5 Unselected events. This causes major pain when you are expiring SolveInstance in the GH component. By using ScheduleSolution, you basically get a built in debouncer that prevents the display glitch and also only results in one downstream execution of the result. The old version of the Human component causes a wave of recompute downstream and sometimes crashes hard on even a small number of objects. Lucky for us @andheum, this is a quick fix by adding a schedulesolution callback that grabs the currently selected objects from the activedoc. I’ve chosen to order objects by guid before passing out because the order of the list is randomized and can change after dragging.
Anyway, happy to have this one tied up! Keep us posted @dale if any changes are imminent. Thanks!
Incidentally, I set the callback delay to 100ms because occasionally you can get a crash at 20-30ms or so for trying to read protected memory from all these events firing. 100ms seems pretty stable but I was able to get it to crash by click-dragging the gumball as fast as possible like a crazy person…