You’d get STL, Alembic, USD, PLY support in addition to the OBJ.

It’s still dependent on the OS it runs on AND the SDK it compiles against (not the OS it was was compiled on).

But that is legacy bridging behaviour, and is not compiled into the app. Apple can and do change those with time.

For example apps that compile against macOS 15 are not opted into Liquid Glass when run on macOS 26 but will be once on macOS 27 according to their transition docs.

That doesn’t really negate the OPs point.

Even if you take away subjective opinions on Liquid Glass, the point is that the core system updates things across the board.

Unless apps have implemented custom drawing, you get a consistent-ish UI (for better or worse) across the system, whereas with windows you are beholden to whatever hodge podge of UI frameworks were chosen at the given time.

If you aren’t in a location with meetups , the best bet is finding online game dev communities.

Especially when it comes to somewhat more specific skills like graphics development.

There’s a reason it was a standard. It made video playback available to systems without accelerator cards, allowed for synchronous DV import and more.

A lot of these technologies seem quaint in hindsight but at the time they were big deals.

Given the rest of your argument hinges on a misunderstanding of the process I’m not sure it holds much merit.

It’s hard to delineate which of these are Chrome features or actual web standards. And it’s therefore hard to blame either Safari or Firefox for not supporting them if they’re not standardized yet.

Another reason to use image sequences is that it’s easier to re-render just a portion of the sequence easily. Granted this can be done with video too, but has higher overhead.

But even then why does the GPU encoding change the fact that you’d send it to another NLE? I just feel like there are a lots of jump in thought process here.

The reason to create image sequences is not because you need to send it to other apps, it’s because you preserve quality and safeguard from crashes.

A crash mid video write out can corrupt a lengthy render. With image sequences you only lose the current frame.

People aren’t going to stop using image sequences even if they stayed in the same app.

And I’m not sure why this applies: “this goes beyond” what Apple has, because they do have hardware support for decoding several compressed codecs (also I’ll note that ProRes is also compressed). Other than streaming, when are you going to need that kind of encode performance? Or what other codecs are you expecting will suddenly pop up by not requiring ASICs?

Also how does this remove degradation when going between apps? Are you envisioning this enables Blender to stream to an NLE without first writing a file to disk?

Bambulabs app will directly read the USDZ if you’re on a Mac for example.