|
|
Spent a good part of the morning going back and forth between svn revisions trying to find which one broke this, and it appears to have started in 1094 where I would expect, but it isn't as frequent there as in the head revision. The only ones I've been able to confirm have been during GC collections, which makes everything skip. |
|
|
|
Considering it skips a few times a second on my end, it isn't likely it has to do with the GC. My guess was that it had to do with the new "set the mouse position every frame" part of the code. |
|
|
|
That change was reverted out before the release. But there was another change that if anything should make stuff smoother, but I guess it's hard to say. |
|
|
|
Ok, it was the world point thing, so I had to revert that to not update unless the actual screen point has updated. I recall having to do this when initially implementing the middle-mouse-scroll (and again when porting it to unity). |
|
|
|
Why on earth would that cause such lag? It's a pretty minor update of one struct. What all else is it cascading into updates? |
|
|
|
It's not lag, it just makes the middle-mouse-scrolling jump back and forth even when the screen point isn't moving, because the world-point is still updating and the middle-mouse operation is moving the world under the cursor, so it never actually settles.
At least, that's what I ran into both during the initial implementation and the unity port of said.
I'll take another brief look, but I've probably spent 10 hours total on the middle-mouse behavior over the past year and it's some of the strangest, most intractable, "just change something and hope it works this time" things I've ever worked with, including ColdFusion ;) |
|
|
|
Ok, I tried some different changes and it seems to not break middle-mouse-scrolling while still updating screen and world mouse coordinates every frame. We'll see if it breaks anything else :) |
|
|
|
Ok -- wow. Didn't know it was such a crazy thing! |
|
