Doing a two-finger pinch on my Mac's trackpad is supposed to zoom in or out in Fusion 360, but I noticed for a while now that this particular gesture is very unreliable. The zoom either happens with a long delay (seconds, not milliseconds) or sometimes it doesn't engage at all.
It is very noticeable and extremely distracting and annoying.
Below is a screen video that documents the delay between when the system starts sending the touch events vs. when Fusion 360 reacts. Make sure to display it in 1:1 full size to see the Terminal window properly.
@paul.clauss, @Phil.E, I usually run with "Perspective with Ortho Faces". I just did a test with the camera set to orthographic, and the result is exactly the same, see new screen video below.
I understand that it takes time to fix bugs and qualify the changes, I'm a SW engineer myself. However it is egregious that this particular bug, which has a very direct and high impact on the core UI, just hasn't gotten any attention over such a long time period. It is a question of prioritization, and as a paying customer (Ultimate), I am not happy with how this has been handled so far at all.
You all do amazing work in engineering, QA, evangelism with great educational content on YouTube etc., and Fusion 360 is a truly incredible piece of software. That's why it's *especially* grating that such an important and jarring issue can just sit for so long while one release announcement after another comes out quarter after quarter with new features.
The problem is: we cannot reproduce it. As you probably already know, no repro means no fix. The trackpad is used and tested by many engineers, pm's, qa, etc. on the Fusion team, and if any of us experienced that we would all know and then would have a reproducible case to fix it. These trackpad issues are not always that easy to figure out, but we never give up trying because your experience is most important to us.
So help us. What is unique about your situation that causes this?
Thanks,
Phil
@teknoel I do see you have crashed once this week, but I don't see any other reports. Please send in CER reports when you get a chance.
Regarding the stability of this build, can you elaborate on this comment?
"Now F360 is the more unstable I have seen in the past year."
I'm happy to track down any new bugs you are experiencing. Please give a description and steps to repeat so I can get the issues logged and fixed.
Thanks,
The frozen UI bug is supposed to be fixed in this release. We used your instructions to debug and fix it, we thought. Are you finding that you can still reproduce it?
Other than that, and slow zooming, is there any other "instability" you can describe that is new to this release?
Thanks,
I've experienced and reported the zoom-lag behavior in the past but as it pertains to how things are working on my machine this has been fixed at least a couple of releases back and I am not experiencing this anymore.
I am on a 2017 high spec macbook pro 15" with touch bar.
I didn't realize you have absolutely no repro case in-house. From some of the comments here it seems that at least some other users experience it as well.
I'll try to get more information then.
- OS is whatever the latest current version is (it doesn't seem to depend on the OS version, as I have had the problem since at least December 2016, and it has happened on all major/minor OS releases between then and now.
- Hardware is "MacBook Pro (15-inch, 2016)" with Touch Bar. I was probably on this same hardware since 2016. I just tried it on another, older MBP "MacBook Pro (Retina, 15-inch, Mid 2015)" and it's exactly the same.
- No special software as far as I can tell. I will do a quick check with a fresh macOS user account to ensure it's not caused by cruft in the settings.
It is puzzling that you cannot reproduce it.
Do you have any debugging logging user defaults or dtrace trace points that you can give me that let me see if the right code in fusion activates when it is supposed to?
Thanks. It is very much my intention to find a repro case.
Here is a video that shows using trackpad.
https://www.youtube.com/watch?v=MiddsbHLV5o&feature=youtu.be
The point is not to say "It works for me", but rather just to show that it does work, which means it's even more important to find out why "not for you". Again, apologies that we have not figured this out yet.
I'm in training this week, so my time is a bit crunched. Would you like to get together next week via phone or other means to talk about this? I'm on Pacific time, US.
Thanks,
Chatting on the phone or something like that sometime next week sounds great. We can set up details early next week.
Thanks for making the video!
To recap, what I'm seeing is a delay of variable duration between the beginning of the zoom gesture and when the app reacts.
- sometimes, it really just feels like a short delay
- but if it's on the longer side, it feels like the gesture just didn't work at all
It looks to me like you hit both issues in your video. The second case seems to happen at 0:19. The first gesture didn't take, and then you had to repeat it. I also think some of the earlier zoom gestures had the slight lag, which is case 1. None of the cases in your video are as bad as the ones in mine though.
@Phil.E To more clearly demonstrate and accurately quantify the issue I wrote a dtrace script and made a new video with the results.
BEGIN { eventcounter = 0; rendercounter = 0; eventtime = 0; printf("time %d ready\n", timestamp / 1000000); } objc$target:QNSView:-magnifyWithEvent?:entry { eventcounter++; if (!eventtime) { eventtime = timestamp; } printf("time %d [thread %d] \033[0;31munhandled magnify event #%d\033[0m\r", timestamp / 1000000, tid, eventcounter); } pid$target::Ns??Scene??ViewRenderer??render(Ns??Scene??EInvalidateType):entry { rendercounter++; if (eventtime) { delay_ms = (timestamp - eventtime) / 1000000; eventtime = 0; } if (delay_ms > 100) { printf("\033[0;31m"); } printf("time %d [thread %d] render #%d delay %dms \r", timestamp / 1000000, tid, rendercounter, delay_ms); if (delay_ms) { if (delay_ms > 100) { printf("\033[0m\n"); } delay_ms = 0; } }
Save this to a file, e.g. "~/Desktop/qnsview.d", and run with:
sudo dtrace -q -p $(pgrep 'Autodesk Fusion 360') -s ~/Desktop/qnsview.d
It will log the start of each magnify touch event as well as the start of each render pass. It will highlight in red two problematic conditions: unhandled magnify events (an event not yet followed by a render pass) as well as render passes that occurred more than 100 milliseconds after the last magnify event that immediately followed a render pass. This captures the perceived sluggishness/failure exactly.
I should add an interesting observation: The camera rotation gesture (shift key held down while moving two fingers on the trackpad) does *not* have the problem. It works fine, every time. Only the zoom gesture seems to have this issue. It also seems that it happens more often with low zoom speeds. When I try to zoom in and out with a faster gesture on the trackpad, it works more often.
If you drop in an extra quanitze() line here:
if (delay_ms) { @delays = quantize(delay_ms); if (delay_ms > 100) { printf("\033[0m\n"); } delay_ms = 0; }
then you get a distribution of the delays at the end when you hit Ctrl-C:
time 27313288 [thread 31211] render #2 delay 103ms time 27314790 [thread 31211] render #16 delay 163ms time 27315660 [thread 31211] render #20 delay 159ms time 27316691 [thread 31211] render #24 delay 155ms time 27317771 [thread 31211] render #29 delay 169ms time 27324801 [thread 31211] render #36 delay 161ms time 27326231 [thread 31211] render #42 delay 405ms time 27337062 [thread 31211] render #115 delay 3592ms ^Cme 27342724 [thread 31211] render #121 delay 0ms value ------------- Distribution ------------- count 2 | 0 4 | 1 8 |@@ 5 16 |@@@@@@@@@@@@ 31 32 |@@@@@@@@@@@@@@@@@@@@@@ 56 64 | 1 128 |@@ 5 256 | 1 512 | 0 1024 | 0 2048 | 1 4096 | 0
That shows that most events get handled within 32ms, but then there are outliers that take multiple seconds. In some of my tests I've seen up to 10 seconds between an event and the first render after it.
You can also change the warning threshold, I use 200ms now. It would be interesting if other people could try this out and report their results. You can download the current version of the script from here:
https://gist.github.com/liyanage/2c49ac0fbb0b259efb753737b83f8654
If you change the "objc" line as follows, you can instead measure the delays for the orbit gesture (which, as noted above, works fine every time):
objc$target:QNSView:-scrollWheel?:entry
The results don't have a single outlier above 200ms:
time 30318832 ready ^Cme 30362607 [thread 31211] render #448 delay 0ms value ------------- Distribution ------------- count 1 | 0 2 | 1 4 | 4 8 | 1 16 |@@@ 35 32 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 359 64 | 4 128 | 1 256 | 0
Hi again.
Does your script/test take into account other compute actions, such as the GPU having to redraw for Level Of Detail? Orbit doesn't encounter this because there is no change in LOD if you aren't zooming.
Also, does the change you are thinking of require Fusion to use a custom Gesture library? That is not allowed for apps on the Mac store. So this makes fixing gesture issues tricky because we cannot modify Gestures as macOS defines them, only consume them.
I'm more interested here in finding why you report 10 seconds for Fusion to redraw the scene, which is the delay you see.
Thanks,