Community
Fusion Support
Report issues, bugs, and or unexpected behaviors you’re seeing. Share Fusion (formerly Fusion 360) issues here and get support from the community as well as the Fusion team.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Mac trackpad zoom gesture engages very delayed or not at all

54 REPLIES 54
Reply
Message 1 of 55
marc.liyanage
5448 Views, 54 Replies

Mac trackpad zoom gesture engages very delayed or not at all

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.

 

54 REPLIES 54
Message 21 of 55
marc.liyanage
in reply to: teknoel

@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.

 

 

 

Message 22 of 55
Phil.E
in reply to: marc.liyanage

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?

  • Can you provide some system details? (hardware/OS)
  • What kind of trackpad - built in, bluetooth,  or other.
  • Any special software installed that involves the UI or input devices?
  • Anything unique about your computer that most Mac users may not have?

 

Thanks,

Phil

 





Phil Eichmiller
Software Engineer
Quality Assurance
Autodesk, Inc.


Message 23 of 55
teknoel
in reply to: Phil.E

This bug is not new and has become much, much worse in this week's F360
update. The fact that Autodesk can't reproduce is rather absurd.

I have two separate Apple Mac setups: A Mac Pro (2012) and Macbook Pro
(2010) of which *both* do the exact same trackpad problems. The Mac Pro
uses an authentic Apple TrackPad 2, while the laptop uses a built-in Apple
Trackpad.

Furthermore, I have taken a new hard drive, installed a fresh Mac OS 10,
and then only installed F360 on the Mac Pro. The exact same F360 bugs show
up.

I've done this fresh system and machine install with:

Mac OS 10.12.6 (sierra)

and then a second time complete wipe and fresh install with

Mac OS 10.13.4 (high sierra)

Nothing makes a difference.


Next question... why is autodesk making upgrading a "no choice"? It's like
ripping the carpet from underneath. Not good in a real, production
environment. Beta platforms should have a discrete method of installation
giving the userthe choice over installed the "Bleeding edge" or last stable
release.

Sorry, I'm quite frustrated with this week's F360 latest release. Things
were pretty darn good for the immediate past version with the help of this
add-in by Pravdomil. However, now not even this add-in will save F360.

https://apps.autodesk.com/FUSION/en/Detail/Index?id=2223881439415941299&appLang=en&os=Mac

Now F360 is the more unstable I have seen in the past year.

- Noel Rubin
Message 24 of 55
Phil.E
in reply to: teknoel

@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,

 





Phil Eichmiller
Software Engineer
Quality Assurance
Autodesk, Inc.


Message 25 of 55
teknoel
in reply to: Phil.E

So the fact that my machine isn't actually "crashing" doesn't mean
"unstable" ... Trackpad behavior doesn't make the machine crash. It's still
unstable.

Again, so many people are stating the exact same thing about the trackpad
gesture inputs. Some users posting elaborative videos that show the issue.

Please escalate this trackpad bug. I also nailed down this "mysterious
whole UI freezing bug" trigger" last year. I spent so much time finding out
the exact trigger for killing the UI, but no fix ever came about that
either. Unbeleivable.

This big in combination with the trackpad issues is rediculous...

https://forums.autodesk.com/t5/fusion-360-support/f360-2-0-3620-global-ui-bug-window-unresponsive/m-...

This one never got fixed either
Message 26 of 55
Phil.E
in reply to: teknoel

@teknoel

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,





Phil Eichmiller
Software Engineer
Quality Assurance
Autodesk, Inc.


Message 27 of 55
teknoel
in reply to: Phil.E

Correct, latest version of F360 still has this frozen UI bug. Easy to
trigger the freezing bug. no change. I just posted a new topic on the forum
to revisit this older issue. It also has the screen capture show the exact
mechanism of the freezing bug.
Message 28 of 55
TrippyLighting
in reply to: Phil.E

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.

Peter Doering
Message 29 of 55
marc.liyanage
in reply to: Phil.E

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?

Message 30 of 55

Just checked, same result with a fresh macOS user account.

Message 31 of 55
marc.liyanage
in reply to: Phil.E

@Phil.E given these results, can you perhaps try again to reproduce it in-house on one of these two systems with the built-in trackpad?

Message 32 of 55
Phil.E
in reply to: marc.liyanage

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,





Phil Eichmiller
Software Engineer
Quality Assurance
Autodesk, Inc.


Message 33 of 55
marc.liyanage
in reply to: Phil.E

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.

Message 34 of 55
Phil.E
in reply to: marc.liyanage

@marc.liyanage you have mail.

 

 





Phil Eichmiller
Software Engineer
Quality Assurance
Autodesk, Inc.


Message 35 of 55
noelQUDAY
in reply to: Phil.E

Thanks for looking into this guys Smiley Happy

Message 36 of 55

@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.

 

Message 37 of 55

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.

Message 38 of 55

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

 

 

Message 39 of 55

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        
Message 40 of 55
Phil.E
in reply to: marc.liyanage

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,

 





Phil Eichmiller
Software Engineer
Quality Assurance
Autodesk, Inc.


Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report