OSX Catalina vs OpenGL vs ProTools 10

[mystran]

The silly thing here is that even if you're software rendering, you're STILL kinda stuck solving these 3D API problems simply because macOS doesn't really seem to have the equivalent of GDI BitBLT in any form that could compete with the performance of uploading a texture and drawing a single triangle. In this case writing the relevant blit-routines against whatever API is mostly an minor annoyance and the main problem is that you simply can't have a single piece of code that works everywhere, but rather have to either pick an API at runtime, drop support for old systems (which is obviously what Apple would prefer) or accept poor performance everywhere.

Agreed, but BitBlt only gets you so far. If you want to do lines and fonts, you want transformations, alpha transparency and color blending all at the same time. And I couldn’t be without a clip rectangle, e.g. glScissor.

You're kinda missing the point I'm trying to make. By "software rendering" I mean a graphics path that literally doesn't touch any graphics API at all, save for single BitBLT to update the actual window. Even then, on macOS (and as far as I can tell) you're basically stuck uploading a texture and drawing a full-window triangle, because just about anything else can take longer than it takes to draw the contents in the first place (where as on Windows BitBLT performs perfectly fine).

[Wallander]

You're kinda missing the point I'm trying to make. By "software rendering" I mean a graphics path that literally doesn't touch any graphics API at all, save for single BitBLT to update the actual window. Even then, on macOS (and as far as I can tell) you're basically stuck uploading a texture and drawing a full-window triangle, because just about anything else can take longer than it takes to draw the contents in the first place (where as on Windows BitBLT performs perfectly fine).

Ok, I get it. You only want to transfer your own offscreen buffer to screen, on the hardware?

I don't think BitBLT actually uses the GPU pipeline. But they're probably doing a direct pixel transfer to the front buffer (or more likely to a backbuffer and swap). If you want to draw directly to screen on the GPU, you don't need to deal with quads or coordinates or anything, because every 3D API has easier functions which do this directly, which bypass the GPU pipeline. E.g. glBlitFramebuffer() in OpenGL. Drawing to a texture, and presenting as a quad, isn't going to be faster, if properly setup.

I haven't tried it myself, but I'm guessing you could do something like that in MetalKit with extremely little code. By using the [MTLBlitCommandEncoder copyFromBuffer:] family of commands.

When I draw in Metal is use an [MTLRenderEncoder] command encoder object. A command encoder in Metal is an instantiated object in which you collect all the operations to be done within a frame, and then you send that encoder to Metal for rendering, asynchronically (I assume). For me, the MTLRenderEncoder object collects everything that's related to shaders, pipeline states, coordinates, textures, color shading, blending modes, viewport size, and so on. In a single frame I draw hundreds or even thousands of triangles, which is very fast, but only because I use static textures. There are different types of encoders, and the MTLRenderEncoder is what you would use for drawing triangles in a 3D space.

But the [MTLBlitCommandEncoder] is a different type of Metal encoder, one that's made specifically for blitting arbitrary data between textures and buffers, and I can only assume you don't need to deal with any of the 3D stuff that relates to the MTLRenderEncoder. You can probably just create a MTLBlitCommandEncoder object instead, add a [copyFromBuffer:toTexture] operation to it, with your offscreen buffer as the source, the texture of your MTKView (view.currentDrawable.texture) as the destination, and send it to the encoder, and that may be all that's needed per frame. MTKView is the NSView class that your view is derived from, equivalent of NSOpenGLView, but for Metal. The complexity level here is on par with using BitBLT, if you know the API.

I should add the disclaimer that I didn't try this myself.

[mystran]

You're kinda missing the point I'm trying to make. By "software rendering" I mean a graphics path that literally doesn't touch any graphics API at all, save for single BitBLT to update the actual window. Even then, on macOS (and as far as I can tell) you're basically stuck uploading a texture and drawing a full-window triangle, because just about anything else can take longer than it takes to draw the contents in the first place (where as on Windows BitBLT performs perfectly fine).

Ok, I get it. You only want to transfer your own offscreen buffer to screen, on the hardware?

I don't think BitBLT actually uses the GPU pipeline. But they're probably doing a direct pixel transfer to the front buffer (or more likely to a backbuffer and swap). If you want to draw directly to screen on the GPU, you don't need to deal with quads or coordinates or anything, because every 3D API has easier functions which do this directly, which bypass the GPU pipeline. E.g. glBlitFramebuffer() in OpenGL. Drawing to a texture, and presenting as a quad, isn't going to be faster, if properly setup.

Look, I'm quite capable of programming GPUs. That's not the point.

Here's my 4kB intro from last years Assembly: https://www.youtube.com/watch?v=V9MPT41wVPU

But... the point I'm trying to make is that one gets dragged into this non-sense of software politics even if one couldn't care less about 3D APIs, because Apple doesn't seem to think it's worth providing a performant non-3D API to copy images from CPU memory to screen.

[Urs]

Oh boys, don't get me started on Apple's software renderer and bitmap pipeline. It's the PACE of graphics. I forgo no opportunity to tell executives how underwhelmed I am.

[Wallander]

Look, I'm quite capable of programming GPUs. That's not the point.

Here's my 4kB intro from last years Assembly: https://www.youtube.com/watch?v=V9MPT41wVPU

But... the point I'm trying to make is that one gets dragged into this non-sense of software politics even if one couldn't care less about 3D APIs, because Apple doesn't seem to think it's worth providing a performant non-3D API to copy images from CPU memory to screen.

Look, I'm only trying to help.

If you're not interested, that's fine. But I just gave you exactly what you're asking for. Which is a device-agnostic method for quickly copying images from CPU memory to screen, using a few lines of code in non-3D but hardware-accelerated MetalKit, a framework provided by Apple. Someone reading this thread may have use for that.

[joshb]

Hey Melda,

I just received your bulk email about Catalina, "OSX Catalina turns the audio industry upside down. Perhaps you are tired with that...".

Wow, I'm a little shocked that you would send such an email to your customers. It's obvious from this thread and that email that you have no love, even open contempt, for the Mac platform, but to encourage users to switch? Really?

Certainly you are entitled to your opinions and business strategies, but seeing as though I'm a Mac user for many years, why would I ever purchase anything else from you?

My 2 cents.

[MeldaProduction]

Hey Melda,

I just received your bulk email about Catalina, "OSX Catalina turns the audio industry upside down. Perhaps you are tired with that...".

Wow, I'm a little shocked that you would send such an email to your customers. It's obvious from this thread and that email that you have no love, even open contempt, for the Mac platform, but to encourage users to switch? Really?

Certainly you are entitled to your opinions and business strategies, but seeing as though I'm a Mac user for many years, why would I ever purchase anything else from you?

My 2 cents.

Hey, thanks for the feedback, but did you read the article? Sure, I have no love for Apple, if you'd read it, you'd know why. And there's no bias in there, all of it is just true. Feel free to correct the fact if I have any mistakes in there.

[JCJR]

At one time Apple Mac was my fav puter. Over the years Apple has managed to groom the most remarkable stable of compulsive hoop-jumpers.

One might almost imagine the top dawgs having cynical sadistic fun with it.

"Ha! Look at our groveling developer slaves! We switched CPU on em twice. We switched blessed language and tools multiple times. For 35 years we changed SDKs and APIs more often than some of those developers changed underwear-- And the silly developers are STILL jumping thru our hoops! Is there any kind of abuse that they WONT tolerate? Hey, lets try this-- We will switch blessed language and CPU one more time while simultaneously changing a bunch of APIs and also making it even more painful to ship software. What do you bet that they will STILL jump hoops even then?"

Reminiscent of the biblical parable of Job. Some developers remain steadfast to the One True OS of Love no matter what plagues are visited upon them in order to test their faith.

The story of Pharoah and Bricks With No Straw also seems relevant...

[MeldaProduction]

At one time Apple Mac was my fav puter. Over the years Apple has managed to groom the most remarkable stable of compulsive hoop-jumpers.

One might almost imagine the top dawgs having cynical sadistic fun with it.

"Ha! Look at our groveling developer slaves! We switched CPU on em twice. We switched blessed language and tools multiple times. For 35 years we changed SDKs and APIs more often than some of those developers changed underwear-- And the silly developers are STILL jumping thru our hoops! Is there any kind of abuse that they WONT tolerate? Hey, lets try this-- We will switch blessed language and CPU one more time while simultaneously changing a bunch of APIs and also making it even more painful to ship software. What do you bet that they will STILL jump hoops even then?"

Reminiscent of the biblical parable of Job. Some developers remain steadfast to the One True OS of Love no matter what plagues are visited upon them in order to test their faith.

The story of Pharoah and Bricks With No Straw also seems relevant...

That's soooo damn true...

[syntonica]

Regarding CPUs, no way is Apple going back to RISC. They are fully invested in arm with the iDevices and the latest chip in the iPad's stomps all over my MacBook Pro in terms of speed (3x faster). The A12X or the next gen will start showing up in the laptops real soon once Apple can tell Intel goodbye. With their low heat and energy requirements, they will then invade desktops. Four of those jobbies will beat the current trash can, can't wait to see what's in the new cheese grater! The macOS and iOS are finally starting to converge to point where the same code base will run on either platform. For better or worse.

I vote for one single universal API for 2D and 3D graphics and leave it to the OS makers to figure out how they implement it. Then, they can use Metal, OpenGL, Direct X, or whatever the hell they want to do. We programmers can just get on with the business of programming and not worry about learning and moving code over to yet another API to bloat the code even more. If Apple can promise that Metal will stick around for awhile and be used for all Apple platforms, then I might bother learning it, but it seems to me this is like the second or third replacement from OpenGL they've come out with...

But yeah, OpenGL is only deprecated for now, which means Apple support for it will now be dismal and it will quietly disappear, like Java support did. While I wanted to take Carbon out behind the barn and put it out of my misery, I was okay with OpenGL and wished it would stick around. It's not the greatest, but it's what everybody knows.

Regarding Catalina, I think most developers will wait for .1 or .2 to come out before they tackle it. It's a whole new beast. I just downloaded the latest Xcode and played with my code in it for a few minutes. Some things are looking very easy, now that 32-bit is gone, but other things made me want to punch a baby. It's definitely not very usable for fully supporting older OSes.

I just ditched Virtual Studio on Windows, I just couldn't take its 4+Gb of bloat anymore. I'm now using minGW, which seems to play nice with my code. VS always complained about something or other. I'll probably take another whack at clang for Windows to see if I can get it up and running. I might also try gnu on the Mac and see if I can get away from Xcode, speaking of bloat, and just stick with the command line tools where needed.

It's going to be strange times indeed from here on out...

[MeldaProduction]

syntonica are you really saying that ARM will be faster than Intel? It's hard to believe that. I checked that these are really better for mobile devices, sure, but for RAW power, no chance apparently. ARM is RISC right?

I agree with the rest. Though I just love Visual Studio (I'm on 2019 though). It has its glitches, but for software that complex it's no wonder. But I'm sure as hell using command line tools for the building.

I wonder what the future will bring , I'm a bit scared though

[Youlean]

Apple arm A12X is almost as fast as Core i7-8559U for example. The next generation or a second one will surpass the Intel mobile CPUs.

BTW, Core i7-8559U has performance similar to desktop: AMD Ryzen 5 1600 or, Intel Core i7-7700K...

https://www.extremetech.com/mobile/2799 ... -geekbench

[Youlean]

Microsoft has already released the Windows on arm, and Apple is expected to release the next Macbook Air on arm next year.

[MeldaProduction]

Ok, but these are still mobile CPUs right?

[Markus Krause]

The OpenGL deprecation is one of the reasons why i did not move to the VST3 SDK so far. It really scares me that all my plugins could stop working with the next OSX update.
I am currently using the Cocoa API which should be safe for the next years.

It is really a shame how Apple treats the developers and customers. It seems that their strategy of deprecating technology quickly has only one reason: To sell new hardware and software and make even more money.

My old Windows programs which are over 15 years old still work without problems. So it IS possible from the technical side but obviously there is no interest from Apple's side for the given reason of profit.