Hi Burr, and probably not so much about 4 times as many pixels to draw, but rather 4 times as many pixels to read back from the card to do hit testing.

Every time you move the view a new set of hit test information has to be read back from the card the next time you do some action with the mouse that needs to do some operation that targets objects like selection or hit testing. So by doing that type of thing where you're changing the view and simultaneously using the mouse you're getting a whole lot of hit test map recalculations which means a lot of stuff needs to come from the card into main memory - some video cards are not very speedy at pulling things in that direction.

Do you have a pretty new video card on this particular machine?

- Michael

Hi Michael,
Did I bring this up before? (Its a repeat from a dead head)

Yes, the issue is moving both devices simultaneously. One or the other works fine.

The other thing is, the split view "all ports visible" is where it works fine. Switching to a single "maximized" viewport is where it rears it's head.

I dont think you should be pulling hair out over it. I can work fine and it's minimal where I try to draw and navigate at the same time. If I need the functionality, I can just work in split view on my 30 inch monitor. No worries.

My card is an Nvidia quadro fx 5600. Although it was always a pretty good card, I guess these days, it may start being called "old" and antiquated!!! Hahahahaaa.

Hi Burr, yeah my current guess is that it's an issue with reading data backwards from the card back to main memory with your video card not being very speedy.

What happens if you turn off object snaps and then do the simultaneous movement while in a drawing command? Does that have any hiccups with a maximized view then or is it not present in that particular case?

When object snaps are turned off, there isn't any object hit testing required by the drawing action and so if that behaves differently that could be a clue. You need to test it while in a drawing command though (like line, polyilne, etc...) not while in selection mode.

It looks like that card is 8 years old, so yeah by video card standards that's actually pretty old.

- Michael

"""""""What happens if you turn off object snaps and then do the simultaneous movement while """"""""""

That doesnt change anything. Empty viewport is fine. Add a sphere and issue is there. No need to be in command or picking type mode. Actually, going into a command, like drawing a curve, creates smooth movement!!! So I place a sphere and get buggard, then start a spline command, and get smooth (Although a little more laggy, which is expected and not some unusual amount)....

Hi Burr, yeah so like I wrote above the turning off object snaps thing will only have an impact in this area when you are in a drawing command, not while you are in "selection mode".

So just let me clarify, please try this:

With a maximized viewport, draw your sphere, then start the Line command.

While inside the Line command test doing the simultaneous motion with object snap turned on file a while (here you see the lag, is that correct), and then try the simultaneous motion for a while with object snap turned off. What happens with it turned off, does it behave very different?

That test should be done all while running inside of a drawing command that picks points like the line command.

If you see very different behavior with object snap on versus object snap off (again I'm just talking about within a drawing command), then that likely points to somewhat sluggish performance in reading data back from your video card.

- Michael

Hi Michael,
So I just want to be sure you understand. Using your last scenario, isnt the issue.

I perform your last scenario of drawing a sphere and starting the line command. I "Do" see a performance difference with snaps on and off, but it is very slight, and on my part, expected and "works fine".

Here's the difference:

Turning on a command, actually "fixes" the issue I was refering to. With just a sphere, and "no command running" (Selection mode), the erratic behavior is present. The rotation and panning "jumps" with large delays in movement (When doing simultaneous movement) In a single maximized viewport only (all of them, whether its front,back or 3d etc)

So to recap, Only in selection mode with a 3d object, not performing anything other than navigation with simultaneous device movement.

Hi Burr, thanks for the additional explanation.... That's kind of mysterious though that it only happens in selection mode.

One thing that I don't quite follow is actually why you would want to do that - what are you trying to do where you find yourself moving both the view and the mouse at the same time, isn't it hard to select objects at the same time that your view is changing?

- Michael

It's more about trying to be "expert" with my 3d navigator. For instance, using the curve tool, then drawing and rotating around the sphere for various pick points! Using my spacenavigator at the same time as drawing and constructing, with 2 hands, in the 3d viewport...

But it is a bit unconventional, and not a normal workflow for me. Hence I didnt want to push for totally figuring it out. I was looking to see if it was a simple explanation found with some understanding of the underlying process.

It may very well be limited to "only my system", in which case, a bunch of time doesnt need to be wasted on why, what etc. on your end.

Hi Burr,

> For instance, using the curve tool, then drawing and rotating
> around the sphere for various pick points!

Does that particular one actually work ok for you though? The curve tool is in a drawing command, not selection mode...

- Michael

Yes, that was the revalation during this discussion.... My first impression just came at initial launch after updating my SN device drivers..... So, outside of a command, I just need to flick the mouse out of the viewport....... :)