"Zooming home" too slow


#1

Hi

Pressing (and holding) the home button (fn + left arrow), after zooming and panning around for a while, is to slow - compared to the windows version. In fact it’s so slow that it’s practically useless (sorry)… It’s just only frustrating.
Pressing “home” (fn + left arrow) once or twice - and then pressing the spacebar after that is a bit quicker… Why?

Could we please have this working like in the windows version?
Thanks!

Philip


#2

the home key (which is on a full mac keyboard but missing from the laptops and wireless keyboards) -or- the command _UndoView

…work better on my MacPro than my mbp.

not sure why… just pointing out that the command _UndoView (which i believe the home key is a shortcut for?) does appear to work properly… just not on all available hardware.


#3

UndoView works as it should, yes. It’'s just that you have to click many times to get back to a certain view… With fn + left arrow you keep the buttons pressed and get back to that certain view much faster - or would, if it just worked as in the windows version…

Philip


#4

from what i can tell, UndoView and the home key are the same thing and work the same way… it’s just that on my mbp, i have to fn+left or UndoView a bunch of times to get back to a previous view whereas on my desktop, it’s usually a one or two step deal.

or- it already works as it does in windows on my desktop.
the navigation works different on a laptop with a trackpad… i’m not exactly sure what the difference is but i know on my laptop, i use the ZoomExtents and ZoomSelected commands a whole lot more because objects lose focus much easier and i have to reset constantly.
i imagine the ill behavior you’re seeing with UndoView has something to do with the difference between trackpad navigation and mouse navigation.

do this-> hook up a mouse to your laptop… navigate the model with the mouse instead of the trackpad then UndoView (or fn+left)… you see the difference?


#5

Nope :smile: Not on my MBP. Pressing - and holding - the UndoView button goes back only one step (to the previous view), whereas pressing and holding fn + left arrow gets you back all the way to the original view if you’re keeping the buttons pressed long enough. It’s just that “long enough” on the Mac side is much slower than on the Windows side (Bootcamp + Win 7), which is the problem. Perhaps it’s only my personal problem - I don’t know if people are using the Home button that much… But as I said earlier…[quote=“Philip, post:1, topic:7164”]
Pressing “home” (fn + left arrow) once or twice - and then pressing the spacebar after that is a bit quicker
[/quote]
… which is strange, I think.

I have a mouse (trying to work with the Magic Mouse) and I know the difference in “zooming home” between the track pad and the mouse… On the track pad it’s really frustrating. It’s just that I adjusted the preferences for zooming with the mouse so I could use a up-down sweep gesture to zoom. That makes the “home-zooming” slower…

I guess I just have to stop using “Home” (which is just an very old habit) and always use only zoom extents, window and selected - and start using a Logitech mouse with a scroll wheel…

It’s just that I think that “Home” should work as smoothly as in WinRhino… :smile: As it is now we might as well just get rid of the command… Sorry…
Thanks!

Philip


(Marlin Prowell) #6

I don’t know why the difference at this point. Logged as a bug to be investigated later.


#7

Thanks Marlin :smiley:

Philip


#8

i think the difference between using a mouse and a trackpad (or a swipe_able mouse) with regards to undoView is that with a mouse:

  • open file
  • push&hold right-mouse button to orbit view
  • release RMB

in that scenario, there are only 2 views which are (basically) defined by when the RMB was released… undoView (or fn-left or home) will go from the second view to the first view in one click of the key.

with a trackpad or swipe, there’s nothing to signify rhino that the user has stopped navigating to a new view since there’s no button we push&release… so it divides the view change up into many incremental adjustments… if we spin the view 90º with a trackpad then undoView, it’s actually divided that single view change into ~15 different view changes so when we hold fn-left, we have to hold it through 15 steps instead of going back to the original view in one step.

and if we’ve done multiple view changes, it takes even longer to get back to our original view since it’s now divided, say, 3 view changes into 50 view changes… at which point, pressing&holding fn-left (or home or UndoView) is a very slow and glitchy affair to get back to the first view.

to fix it, i guess it would require rhino to recognize 2fingers touching the trackpad signifies the beginning of a view change and only when those two fingers are finally lifted does it remember a second view has been reached.

other ways around it would be to require a key press in order to zoom/rotate in which the key press + finger signifies the beginning of a view change then releasing the key signifies the end of the view change.

or, (and this is a good way to test the differences) use the commands RotateView, Pan, and Zoom to navigate the model… (which would be lame if we had to navigate that way but…)

[EDIT] i guess another way to ‘fix’ it would be that view changes are time controlled… if the model hasn’t been navigated for ,say, 5 seconds then a view will be remembered… not sure how well that would work out in the real world but just thinking out loud now.[/EDIT]


@Philip - for clarity, if you use the _RotateView, _Pan, and/or _Zoom->dynamic commands to navigate a model, does fn-left then act as you’re expecting?
(because if not, i’m seriously not understanding what you’re saying in all of this and i’ll bow out of the conversation :wink: )


#9

aside from the exact topic at hand (fn + left arrow key)…

i wonder if there’s a performance hit taking place if a user navigates with a trackpad?
since all of these incremental (and unnecessary) views are being remembered by the system.
?

or maybe camera position data is so minuscule in size that it doesn’t really matter anyway?


#10

Exactly!

That’s exactly what I was going to suggest - and the same behavior with one-finger-sweeps on the Magic Mouse!
This is how AutoCAD (Win) works with the scroll-wheel, which would be a be a good thing to get in WinRhino as well (wish: @pascal)! As it is now Rhino is ‘zooming home’ going trough each click of the wheel, if you understand what I mean…

I think so IIRC - I’m at work now and I haven’t got my MBP with me. Have to check after work…

Philip