It's a lifetime management system for short-lived objects, same idea as memory arenas but for manually refcounted objects you got out of an API. It keeps the object alive until the end of the autorelease scope without anybody having to explicitly call the release method (the autoreleasepool does this instead). Not sure if the concept still makes sense with ARC though, it's probably just a no-op there - or probably not seeing that Swift seems to have inherited autoreleasepools from ObjC).
There's an autoreleasepool around the per-frame code - which seems to be standard procedure for Metal code - so any object within a render frame that has been created with autorelease will be released at the end of a frame.
Metal has a couple of 'frame transient' objects (like MTLRenderPassDescriptor and MTLRenderCommandEncoder) which have a new instance created in each frame, and I guess the main job of the autoreleasepool is to clean up those transient objects (along with any other 'short-lived-junk' that might be returned from Metal API methods).
And my guess for why this is still needed in the age of ARC: I guess that ARC has a 'autorelease-blindness', e.g. it cannot figure out at compile time what objects are registered with autorelease pools (especially when the objects are passed across DLL boundaries) - it can only add retain/release calls on top. Just speculation on my part though.
The render thread is running an infinite loop. You need to manually drain the autorelease pool, otherwise autoreleased objects created during rendering won't be released until the thread exits (there's an implicit top-level pool in each NSThread which is drained on exit). In UIKit/AppKit, the autorelease pool is drained at the end of each NSRunLoop iteration by the framework, so you don't typically drain it yourself. Here they created their own runloop - an infinite `while` loop that calls `onRender()` - so they must drain the pool themselves.
If Google is paying Apple effectively not to make its own search engine, I would not be surprised if Apple and/or Microsoft were paying Adobe not to port CC to Linux.
I don’t think we need a conspiracy theory. Most likely they don’t bother with 5% market share, most of which probably have strong feelings about closed source in general and Adobe in specific.
Wasn't Mac OS less than or around 5% for a long time after the 90s? If they thought that was sustainable, maybe Linux should be close by now? Of course there are many other things to also take in account, so who knows.
Most apps started on the Mac, so there was no porting needed. Also, most professionals had Macs, so Adobe had a 50/50 revenue split between Macs and Windows, even though there was a huge market share difference.
I just tried it recently, worked well enough, including support for std vector, string etc. You can loop over std vector items using a standard Swift loop, for example. It´s clear Apple needs and uses this internally too.
It can be done, and Valve are old-school gamedev bros who clearly are interested in making it happen for games on their platform. But not every shop is like that, and in particular I wince when I contemplate updating a PS4 game...
Personally it is more about avoiding big relative errors: 1 month ago can be between 10 and 45 days ago (maybe, nobody knows how the rounding works). 8 months ago is less of problem
reply