Moving Acorn to Metal
IOSurface is neat. A shared bitmap that can cross between programs, and it’s got a relatively easy API including two super critical functions named IOSurfaceLock and IOSurfaceUnlock. I mean, if you’re sharing the data across process boundaries then you’ll need to lock things so that the two apps don’t step on each other’s toes. But of course if you’re not sharing it across processes, then you can ignore those locks, right? Right?
[…]
What I couldn’t do though, was make a CIImage directly from that IOSurface. Every time I tried, I’d end up with an image that was either 100% blue, or 100% red. I had convinced myself that these were some sort of mysterious debugging messages, but I just hadn’t come across the correct documentation letting me know what it was.
[…]
Yes, you can use a CGBitmapContext with an IOSurface without locking it. But then some other frameworks are eventually going to grab that same IOSurface for drawing and they are going to lock it and then some crazy black magic is going to swoop in and completely ruin your image. Even if you aren’t using it across processes. So you better make sure to lock it, even if you’re not actively drawing to it, or else things are going to go south.
Update (2017-12-28): Gus Mueller:
And then there’s the issue of actually trying Metalcorn (get it, Metal + Acorn?) on another machine. Up to now it’s been on a couple of iMacs. But I threw in on a 2012 MBP the other day and wow, it was janky and not at all what I was expecting. Rendering problems related to alpha channels, jittery behavior, and general funkyness.
When rendering through GL + CGBitmapContexts I always got predictable behavior that scaled linearly with the CPU power of your machine. Not so with Metal.
