TOPIC:

I just purchased a:
2022 MacStudio M1 Max 10-core 64GB RAM, 2TB SSD
to replace a
Late-2014 5k iMac Quad core i7 24GB RAM 512GB SSD

This was in particular to get Motion moving more smoothly. I have a short motion project that includes a flame particle emitter that I am animating along a path. On my iMac I got the spinning beach ball every time I pressed play or moved the emitter at all. I thought that would improve on the MacStudio, but not much, to be honest.
I tried it with the Motion file on an external SSD (Samsung T7), and also on the internal 2TB SSD in case the disk was the bottleneck. I consolidated all media to the SSD and detached the Samsung T7. No difference.

Am I misunderstanding something regarding which elements will improve speed for such apps?
To my surprise, Adobe Photoshop is noticeably faster, despite not being Mac native

Any tips welcome. TIA.
Suzanna

I ran the BruceX benchmark on my 2017 i7 iMac 27 (running FCP 10.5.3 on Catalina) vs my M1 Max MacBook Pro (running FCP 10.6.3 on Monterey) and the M1 Max was about 3.5x faster.

However benchmarks measure different things, and exactly what software "load path" they are measuring is not always obvious (or even knowable). The BruceX benchmark is a GPU-oriented test using standard Final Cut generators, titles and transitions. All built-in FCP effects are Motion-based but what aspect of Motion each one stresses (or even the internal architecture of Motion) is unknown.

It appears that Motion is based on a runtime engine which interprets template directives. I don't know if those are always interpreted, sometimes compiled, "just in time" compiled, or to what extent the Motion runtime engine is require in various cases. If it involves a runtime engine, one question is to what extent can the additional M1 Max CPU cores be leveraged in parallel. Another question is what is the CPU/GPU workload split when executing your Motion template. When you play a project in Motion, you can optionally render a RAM preview. Does that make your project faster?

If you could upload a sample Motion template we could test on various machines, that might help.

Thanks for the report. I was wondering about Motion's performance on the Mac Studio.

I have noticed that Motion templates tend to play better in FCPX, than they do in Motion itself. Apple seems to have treated Motion more as a development tool for Final Cut plugins than an actual end user animation software. As a development tool, it works pretty well, and rough around the edges is ok. As an end user animation tool, not so much. Why can I not view my projects on an external display? Why can I not see my inspector and Library at the same time? I have a huge wishlist for what I would like it to be.

Motion has been around since 2004, and while new features have been added, it is still very much the same. It didn't receive the big overhaul that Final Cut X did. For all I know it is using the same 2004 code at its base. I would love to see Apple to turn it into a proper competitor for After Effects, but it needs an overhaul. (So does After Effects which runs best on my old 2013 iMac!)

MWoods wrote:

...For all I know it is using the same 2004 code at its base. I would love to see Apple to turn it into a proper competitor for After Effects, but it needs an overhaul...

It must have been somewhat upgraded since 2004 to go from Carbon to Cocoa and then to 64-bit. I've never studied Motion internals but from studying various FCP crash dumps, parts of FCP have been re-written from Objective-C to Swift. At a recent WWDC Apple basically suggested that developers of heavily multithreaded apps rewrite the thread management from Grand Central Dispatch to the newer Swift Concurrency. That has evidently not yet been implemented in FCP since I've seen several failures involving "thread explosion" which Swift Concurrency is designed to avoid.

Since Motion underlies almost all built-in FCP effects, it has a pervasive impact. There are apparently issues with the Motion runtime engine whereby it interferes with FCP caching in many cases. This can be easily reproduced by using a compute-intensive plugin like Neat Video, add the built-in FCP Title effect, don't change any defaults, render to cache with CTRL+R and export will be lightning fast. Then change the default text from "Title" to "Titles", re-render to cache and despite no render dots, export will be very slow.

That one change somehow causes FCP to effectively mark the cache as invalid during export and recompute all effects in the stack. It may be related to limitations in the Motion runtime engine. Motion was originally designed as an interactive app "so fast you never need to render", not as an NLE effects engine.

The limited rate of change in Motion might imply some original clever developers devised a fast, efficient architectural design which later developers found difficult to upgrade. Part of that difficulty might include harnessing parallelism from high-core-count CPUs during certain tasks. Blackmagic faces a similar problem in improving Fusion performance scalability.

I agree there is a lot you could do to make Motion better.
Just keeping the windows as a default setting would be nice.
Every time I open motion I have to reselect cinema windowing.
Performance on Mac Studio is not always optimal.
I do get quirks here and there as I work.

Thanks for all your replies so far.

I'll admit that all the info about Grand Central Dispatch / Swift Concurrency etc. goes way over my head - but I do understand that Motion is alas not as streamlined as I'd hoped and it's not necessarily the Mac Studio's fault.

@Joema You asked for an example of the project. I have it here, consolidated. I'm curious if you can find anything that might be slowing down this particular project. Thanks in advance for taking a look.

suzero.wetransfer.com/downloads/999a8cc7...0220811141554/0db555

Suzero wrote:

...@Joema You asked for an example of the project. I have it here, consolidated. I'm curious if you can find anything that might be slowing down this particular project. Thanks in advance for taking a look.

I tried it on my top-spec M1 Ultra. You are right -- there is some problem. It's super slow and gets stuck in a beach ball frequently. Unfortunately I'm not familiar with Motion or common performance issues.

I took a spindump during one of the beachball hangs and a fragment of the "heaviest" trace is below. Each time I did this, the stack trace was mostly similar. This implies it gets stuck waiting on a mutex to obtain some asset within the app. But what causes that I don't know. A few interpretational items:

- You read it from top to bottom, unlike a crash stack trace that's read from bottom to top.
- The number at left is # of times the function was present when the process was sampled.
- Functions with NS prefix mean (NextStep), those are APIs inherited from NextStep
- Functions starting with OZ mean Ozone, which is the Motion rendering engine
- Toward the bottom this thread tried to obtain a lock on some asset. That was in
OZLockingGroup so it was an application-specific lock.
- PCSharedMutex is a Mutual Exclusion Object used to coordinate multi-thread access to some asset.
The PC prefix implies it's part of the Apple ProCore framework.

See attached .txt file.

Interesting. I was curious, so I tried it on my 2017 iMac Pro. I can report that it plays back perfectly smooth on this machine at the project's frame full rate of 25fps. No Ram Preview required. I did get a second of beachball when I stopped playback, but not long.

Update. I am getting beachballs and slow response time when I try to make changes though.

Suzero wrote:

...example of the project. I have it here, consolidated. I'm curious if you can find anything that might be slowing down this particular project. Thanks in advance for taking a look...

It's very slow on both an 2019 i9 Intel MacBook Pro 16 and my top-spec M1 Ultra. Apparently it's caused by the Random Motion simulation behavior. If you remote that one item, it becomes fast.

I'm not familiar with Motion, I simply determined this by a lot of trial and error experiments. I don't know if there are known issues with the Random Motion behavior: support.apple.com/guide/motion/random-mo...a11/5.6.1/mac/11.5.1

Whatever the problem is it's not caused by Apple Silicon and cannot be fixed by Apple Silicon. When Motion is in that mode it's not CPU bound, GPU bound or I/O bound. Rather it's in a wait state based apparently on inter-thread coordination. No amount of CPU, GPU or I/O capacity will fix a problem with the app is internally deadlocked.

The next step is someone with more Motion experience should review this and then probably contact Apple support.