For this sort of thing, adding another layer of indirection (and another dependency, developed elsewhere with potentially different priorities) is much more likely to end up being a 'now you have two problems' kind of scenario.
Of course, they could go full dx12 on Windows, Vulcan on Linux and Metal on Mac, but precisely because their needs are not that demanding in the graphics department, I imagine the incentive is to keep it simple
The Vulkan drivers should be at least as available as OpenGL on both Windows and Linux. So it would make sense to target Vulkan and thus benefit from a shared codebase.
And if their Mac client base is not big, it should make even more sense to experiment with MoltenVK (lower risk).
Anyway, they probably have good reasons for that choice. Just wondering what those are. Perhaps Oracle is not big on relying on community projects like MoltenVK?
Now I'm curious to what degree the graphics rendering is responsible for IntelliJ's sluggish, battery-hogging experience on macOS. I wouldn't think it's the main cause, but who knows
I don't find it to be any more sluggish on my Mac compared to my coworkers on Linux. If anything I have a better experience than them due to various random Linux UI glitchiness (which could probably be attributed to the specific hardware they are using, but still).
The classic example would be real-time applications where hard envelopes in terms of response times are required and GC pauses must _never_ happen. But even in these cases it is possible to do a lot:
- write garbage-free code (reuse objects and byte buffers, allocate memory off the Java heap and store the pointers in `long`s)
- use a GC that doesn't pause and carefully profile the app to ensure the GC can keep up with the rate of memory allocation
- turn off the GC and cross fringers if the app crashing is considered better than not responding
It's just difficult because most software is written using software patterns that require a GC, which is perfectly fine for many domains.
I have a Hackintosh with an 10980xe and 128GB RAM.
I tried this Metal build and it doesn't make it any faster. Pretty sure it's all of the background indexing and compilation it is doing because there is no app that can push all of my cores to 5GHz like IntelliJ can.
You’d think Apple would just hire someone to do this for them, in Java. There are maybe 10,000 concerns they could pay for to resolve, with clear no nonsense objectives like “Does Java2D run on Metal?” And the crazy thing is they have the money to do it.
That's interesting - what is Apple building on Java? They're still on Java 6 I think? I thought they deprecated their Java system APIs years ago as well?
Been a while since I worked at Apple but it would likely still be:
- Apple ID
- Apple Online Store
- App Store
- Bug Reporter/Radar
- iCloud Apps e.g. Mail.
- iTunes Connect
- iTunes Store
- WWDC
Pretty much all of the internal apps will be in Java unless they are using off the shelf software e.g. discussions. In addition you would have all of the companies they acquired and whatever tech stacks they use e.g. Siri.
Apple have an OSS framework built on Netty (whose lead developer is employed by Apple) named ServiceTalk, and this talk [1] says that almost all back end services are Java-based.
I have no idea where the idea of Java 6 being in use comes from.
> where the idea of Java 6 being in use comes from
Possibly from confusion with the last time Apple actually shipped a JDK/runtime to the public. They used to produce their own optimized distribution, which had better Cocoa widgets among other things. It was part of the original big push to get decs on OSX, it’s mentioned in Jobs’s keynotes etc. They later deprecated it once they reached critical mass, and discontinued it; if i remember correctly, the last jdk they shipped was a v6.
Yes, it’s more likely that an app written with Swift/Obj-C and AppKit/UIKit/SwiftUI will be more tailored to macOS specifically and will better take advantage of platform facilities than apps written with a different language and toolkit (such as Java+ Swing). Apps built with third party tools tend to be more lowest-common-denominator.
Nobody cares, proved by electron and popularity of web apps in general. The only b thing Apple will achieve is to speed up the native going into irrelevance and being replaced with things like electron. Regular people don't care about "looks and feels native" zealots. All the relevant software has distinct, software specific looks. Adobe suite, Fusion, bunch of engineering tools, IDEs.
Regular Mac users _used to_ care. For many years, one of the defining characteristics of Macs was the high quality native apps, all with consistent look, feel and behavior. Mac users would refuse to use apps that weren't sufficiently Mac-like. Developers of Mac apps had a similar passion and perfectionism for good UX and UI.
Somewhere along the way, this part of Apple culture got lost. I think Apple's commercial success is part of the reason. The traditional Mac user base got diluted by lots of newcomers who didn't have the same high expectations and requirements for good and consistent user interfaces. The traditional Mac developers got diluted by programmers from other platforms, who – although not being technically inferior in any way – did not have the same passion or understanding of Apple's UI philosophy, often not even bothering to study the Human Interface Guidelines.
Funny thing is that those are both products that many are reaching for alternatives to whenever viable. As powerful as they may be as tools, there's quite a lot that's throughly mediocre or even bad about them.
There are examples of truly great apps that use their own look and feel, but I don't think either of those are among them.
This specific thing is much more a JetBrains (and their customers) problem than an Apple problem and it looks like they've managed to put together a good solution - do the work and have some assurance it's going to end up in the mainline OpenJDK. They've been selling their tools on macOS for many years, have shipped plenty of custom JDKs before, it's safe to assume they have a decent idea what they're doing.
“Does Java2D run on Metal?” doesn't seem like a top 10,000 question for Apple. It does however seem like a top 10 question for JetBrains. And so here we are.
I think swift is more of a means than an end, but yea they haven't had much JVM support for a long time looking at wikipedia. This is a little nuts to me—I first learned to use cocoa with Java!
They don’t want to be running around making Swing and SWT and Qt and Gtk work well on macOS. They offer their own and you can take it or leave it. I guess this lets them simplify and focus. It obviously works for them.
I have gone through something similar recently (implementing nanovg on top of Metal). It’s a really good experience and can be achieved with relatively little code.
I would have expected a performance increase to be honest
Or maybe they push the limits of POSSIBLE perf because of the JVM, i guess that's why performance gain can't be perceived, no matter what, the JIT and GC has to constantly work..
They're aiming to get off a dead API as quickly as they can. All they have to do is match performance (no regression) and they're happy. They don't need to increase performance. That can be a separate project. Maybe you want to do it?
The OpenGL-based implementation is pretty damn mature, and it’s probably well optimised. The new Metal implementation is an early access release, at a stage in the project where performance concerns are more like “don’t do stupid things” than like “extract every last ounce of performance out of it”.
Honestly, I've been looking into starting projects on it because it's mature and I can have some confidence that a jar I compile today will work in ten years.
Why is Apple still dead set on having their own special graphics API? Surely it would be better for everyone (even them) if they just adopted Vulkan like literally every other platform?
I would be surprised if the graphics API layer had a particularly big impact on power usage. One of the stated goals of Vulkan is also to reduce CPU load when rendering.
All it does it make software (especially games) less likely to be ported to iOS/macOS. And they have to maintain a graphics API, which isn't a small task. How is that a good thing for them?
This isn't really something that helps or hinders locking consumers into their ecosystem.
iOS has no shortage of games, so that doesn't seem like a problem. And maintaining their own graphics API lets them fully integrate it into the rest of their hardware and software stack without the baggage that comes with a cross-platform standard.
iOS is a pretty big market, I would argue that they have lots of games despite not supporting open standards, not because. Gaming compatibility on laptop/desktop macOS is pretty piss poor. (Although Blizzard has always been really good at supporting mac).
What does Vulkan brings to the table apart form so called cross platform compatibility? Which is a bit like Cross Platform Apps, they are just never as good as Native Apps.
It is not in any ways better than Metal. And when you design your own Hardware, it makes much sense to own your API design for maximum performance.
I would have loved to have seen a Vulkan implementation combined with MoltenVK[1] for Metal compatibility instead of a direct Metal implementation. This means that Java will now have to maintain two separate graphics implementations.
There are times like this I feel electron is not bad of a platform. Platform APIs keep on changing but chromium always implement those in early phase(vulkan, metal, ARM mac OS etc). Development almost never have to worry about platform APIs.
Maybe in a couple of years when they get the resource consumption way down. And even web stuff runs better with the "native" implmentation, slack running on safari (really cant find it now, it was posted here a while ago)
79 comments
[ 3.0 ms ] story [ 148 ms ] threadhttps://github.com/KhronosGroup/MoltenVK
Battery life might be a good reason
And it's hard to imagine Java2D would have more complex requirements for Metal than the games that are already using MoltenVK.
Of course, they could go full dx12 on Windows, Vulcan on Linux and Metal on Mac, but precisely because their needs are not that demanding in the graphics department, I imagine the incentive is to keep it simple
And if their Mac client base is not big, it should make even more sense to experiment with MoltenVK (lower risk).
Anyway, they probably have good reasons for that choice. Just wondering what those are. Perhaps Oracle is not big on relying on community projects like MoltenVK?
- write garbage-free code (reuse objects and byte buffers, allocate memory off the Java heap and store the pointers in `long`s)
- use a GC that doesn't pause and carefully profile the app to ensure the GC can keep up with the rate of memory allocation
- turn off the GC and cross fringers if the app crashing is considered better than not responding
It's just difficult because most software is written using software patterns that require a GC, which is perfectly fine for many domains.
I tried this Metal build and it doesn't make it any faster. Pretty sure it's all of the background indexing and compilation it is doing because there is no app that can push all of my cores to 5GHz like IntelliJ can.
- Apple ID
- Apple Online Store
- App Store
- Bug Reporter/Radar
- iCloud Apps e.g. Mail.
- iTunes Connect
- iTunes Store
- WWDC
Pretty much all of the internal apps will be in Java unless they are using off the shelf software e.g. discussions. In addition you would have all of the companies they acquired and whatever tech stacks they use e.g. Siri.
I have no idea where the idea of Java 6 being in use comes from.
[1]: https://youtu.be/Ms8vriZ6ieU
Possibly from confusion with the last time Apple actually shipped a JDK/runtime to the public. They used to produce their own optimized distribution, which had better Cocoa widgets among other things. It was part of the original big push to get decs on OSX, it’s mentioned in Jobs’s keynotes etc. They later deprecated it once they reached critical mass, and discontinued it; if i remember correctly, the last jdk they shipped was a v6.
i.e. it's probably more about fostering great UIs for the end customers rather than curbing Java altogether as a platform.
Somewhere along the way, this part of Apple culture got lost. I think Apple's commercial success is part of the reason. The traditional Mac user base got diluted by lots of newcomers who didn't have the same high expectations and requirements for good and consistent user interfaces. The traditional Mac developers got diluted by programmers from other platforms, who – although not being technically inferior in any way – did not have the same passion or understanding of Apple's UI philosophy, often not even bothering to study the Human Interface Guidelines.
Funny thing is that those are both products that many are reaching for alternatives to whenever viable. As powerful as they may be as tools, there's quite a lot that's throughly mediocre or even bad about them.
There are examples of truly great apps that use their own look and feel, but I don't think either of those are among them.
They don’t want to be running around making Swing and SWT and Qt and Gtk work well on macOS. They offer their own and you can take it or leave it. I guess this lets them simplify and focus. It obviously works for them.
I would have expected a performance increase to be honest
Or maybe they push the limits of POSSIBLE perf because of the JVM, i guess that's why performance gain can't be perceived, no matter what, the JIT and GC has to constantly work..
So it's more a case of they built the API for themselves first and then made it available for developers.
They also have power consumption and mobile performance as being their highest priorities which may not align with Vulkans.
This isn't really something that helps or hinders locking consumers into their ecosystem.
It is not in any ways better than Metal. And when you design your own Hardware, it makes much sense to own your API design for maximum performance.
What other platforms? The only ones I see adopting Vulkan are Desktop Linux and some newer Androids. The first effectively doesn't even matter.
The games consoles don’t use Vulkan either. It’s a niche API.
[1] https://github.com/KhronosGroup/MoltenVK
"Please don't cancel the project! You'll own it all anyway!"
*Lanai is the Hawaiian island that Larry Ellison owns
It would be nice if they could start working on supporting Wayland and in turn HiDPI on modern desktops.