MacOS High Sierra tech preview: A quick look at the stuff you can’t see | Hacker News Reader

MacOS High Sierra tech preview: A quick look at the stuff you can’t see

arstechnica.com

94 pointsrbanffy29 comments

It does worry me that Apple is walling itself off from the ecosystem of OpenGL even further. However, if most developers will only ever interact with Metal through game engines, hopefully it won't matter too much since the popular engines are supporting it.

It won't matter since Metal was released in 2014 and Vulkan in 2016 including OpenCL will be merged into Vulkan API.

If most developers are targeting iOS and macOS for gaming, it make sense to use game engines, if I understand some developers had shared their discussion in /r/vulkan found it was harder to code in Vulkan than Metal 2?

> If most developers are targeting iOS and macOS for gaming

There are applications beyond gaming, however, and it is still kind of a drag that OpenGL is still the only de facto cross platform API in the space, and that it has miserable support on macOS.

What are the prospects of just wrapping OpenGL on top of Metal? Genuinely curious, since I haven't taken a deep look at Metal yet and have kind of been out of the 3D graphics biz for some time now.

It's happening, and that's basically the future of OpenGL (a library on top of Vulkan / DirectX 12 / Metal). It will be a while, though.

> It's happening

Are you aware of any project that is under development right now? I know it's theoretically possible, but I haven't seen any implementation yet.

A quick search points to a commercial project: MoltenGL[1] (I'm not affiliated with them at all, just googling).

1: https://moltengl.com

Speaking from personal experience - hobbies only - that sounds about right.

Vulkan is not very nice to work with. It's.. ok.

Metal is nicer

A very nice thing about Metal is that the API is OO, targeted at Objective-C and Swift, with the shaders being a subset of C++14.

Khronos APIs keep being stuck on their C API definitions, it was NVidia effort to create a C++ wrapper that eventually made it into Vulkan, yet the shading language is pretty bare bones.

Similarly with Metal Compute shaders, Khronos had to see CUDAs and C++AMP adoption to see that many wanted something more productive than OpenCL C. However not many boards do support OpenCL 2.2 with SYCL.

Right - higher-level interfaces are usually nicer to work with, be that at a language level or abstraction level.

Metal is a nice balance.

Ditto with HEVC and HEIF. With the even higher royalty fees of HEVC and HEIF, availability of alternative royalty free formats backed by Apple's competitors, Apple will be walling itself off once again.

HEVC is becoming very standard for 4K (and sometimes for non-4K) video. Even torrent sites have loads and loads of H265 content now.

Aside, I really prefer the fallback rendering for hevc in lower bitrate encodes... the "blurry" is way better than avc's "blocky". So even when it's technically less accurate than h.264 in many conditions, it still looks better.

Webp didn't took off as we would like, I'm still using JPEG, SVG and PNG for all artworks. I believe Microsoft and major graphics editing have plans to support HEIF because their software are running on macOS and iOS. Affinity Photo and Designer surely will.

Web browsers might supported HEIF largely because Imgur and other image hosting will benefits from smaller size.

I don't think this comparison makes sense - HEVC and HEIF are both industry standards, and will probably see widespread adoption. HEVC (H.265) is already really taking off, especially now most modern Intel CPUs have hardware support for it. Their main predecessor technologies, JPEG and H.264, weren't 'open' formats either.

In the case of HEIF, MacOS/iOS will automatically transcode to JPEG anytime you share a HEIF image - it's solely being used to save storage space on your personal device, so in reality almost no one will even notice the change, save for the upside of having more free disk space. H.265/HEVC is pretty trivial to transcode to H.264 or whatever else you want, but given how wide support is spreading I doubt people will often have to do this.

Metal on the other hand is an entirely Apple in-house technology.

This again.

(1) WebM/VP9 is only royalty free because MPEG-LA et al have not asserted any patent claims against it. Given that VP8 was granted a license in the past means that it is almost certain to be infringing. The fact that Google doesn't indemnify their users should tell you something.

(2) H.265 is supported by over 100+ more companies than VP9 and is already in shipping hardware from Sony, LG, Samsung, Intel, AMD, ARM, Nvidia etc. It is the standard for TVs and other hardware devices, standard for terrestrial broadcast and will soon be the standard for internet as well.

Yeah, it's like how we had to stop using GIF and MP3 because of the all the licensing issues.

Wait, no...

There's no future in supporting OpenGL directly, the future of OpenGL is libraries which implement OpenGL on top of Vulkan / DirectX 12 / Metal. OpenGL is simply too far removed from the way modern graphics pipelines work to keep supporting it as a primary target.

I think Vulkan was meant to be included under the banner of "OpenGL" in the parent post. It seems to me the point is that Apple is doubling down on its proprietary API rather than going with the standard.

Well, MS doesn't go with the standard either, and they have 90% of the desktop market.

So why stick to something that will at best be a second rate citizen on Windows too?

And Microsoft is on major version 11 of their proprietary graphics API.

Ever have things been this way. It shouldn't be a surprise when they continue to be.

The 11th major version, but version 12 actually. (DirectX 4 was skipped)

Of course Apple is doubling down on Metal. So much of the future of their platform depends on it e.g. ARKit, CoreML. And so having that rest on top of a core technology that (a) they don't control and (b) isn't optimised for their hardware is a mistake.

The better option is to provide a Vulkan/OpenGL shim instead.

This seems like an argument against any standards at all and for NIH as a guiding principle. Using the logic presented here, you could just as validly say that WebKit shouldn't support HTML and CSS since they're not proprietary and not optimized for Apple's hardware and a lot of stuff rests on top of WebKit. Surely you don't actually think that, but I can't figure out how you can not think that but still think that "it's an open standard" is a knock against Vulkan.

Which is exactly what happens with all those HTML, CSS and JavaScript extensions.

Some get adopted, some dropped and others stay browser specific.

One thing that they didn't mention on the article, but it was talked about at the Metal 2 WWDC sessions, is that they ported the Window Manager from OpenGL to Metal 2.

Also SceneKit and SpriteKit had quite a few Metal 2 improvements and OpenGL replacements.

They also had someone from Disney showing how they are adopting Metal 2 on their workflows.

So that should state to which direction the wind is blowing.

However as you say it doesn't matter, because all major 3D and 2D engines already support Metal, or are in the process of supporting it.

One thing that they didn't mention on the article, but it was talked about at the Metal 2 WWDC sessions, is that they ported the Window Manager from OpenGL to Metal 2.

Note that this is mentioned in the article:

Apple says the entire WindowServer is now using Metal, which should improve the fluidity and consistency of transitions and animations within macOS; this can be a problem on Macs when you’re pushing multiple monitors or using higher Retina scaling modes on, especially if you’re using integrated graphics.

Thanks for the heads up, I should have read it better.

I've been waiting for fahrenheit back in the days. I have the beta sdk here on cd. I have absolutely no reason to trust khronos to push things forward.

Apple is doing the right thing here. Gamedevs use engines anyway

Reply on news.ycombinator.com