6 ms·
Metal for IntelliJ Platform
- johnisgood 6y agoIt consumes less energy? By how much, and was this the main motivation?
- jmarcher 6y agoThe main motivation is OpenGL being removed from macOS at some point.
- gravypod 6y agoI'd assume there's other considerations because if that were the only concern why not go with Vulkan, an industry standard? https://github.com/KhronosGroup/MoltenVK https://github.com/KhronosGroup/MoltenVK Battery life might be a good reason
- pvg 6y agoFor 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.
- hvis 6y agoBut they would have both a macOS port and a cross-platform Vulkan port then. "Two birds, one stone" kind of scenario. And it's hard to imagine Java2D would have more complex requirements for Metal than the games that are already using MoltenVK.
- Macha 6y agoOpenGL is still "fine" on Windows and optimal on Linux (which if their survey is accurate, are both larger platforms for them than Mac https://www.jetbrains.com/lp/devecosystem-2020/ https://www.jetbrains.com/lp/devecosystem-2020/ ). 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
- hvis 6y agoThe 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?
- p1necone 6y agoFrom what I understand MoltenVK is not super efficient compared to native Vulkan on other platforms.
- brundolf 6y agoNow 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
- adamnemecek 6y agoSluggishness is caused by the fact that it's Java.
- p1necone 6y agoIt's not sluggish at all on Windows and Linux. "Java is slow" is a silly meme, it doesn't reflect reality.
- somehnguy 6y agoI 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).
- p1necone 6y agoThat's true. It can be a total nightmare trying to configure stable hardware rendering on a lot of linux distro/hardware combos.
- adamnemecek 6y agoIt's not a meme. Garbage collected language just can't be used for certain things.
- sitzkrieg 6y agothey are great for desktop IDE software though
- an_opabinia 6y agoYou’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.
- adamnemecek 6y agoApple has vested interest in users not running Java on their platform.
- onewland 6y agoI've worked at Apple and hundreds if not thousands of their devs use Java
- chrisseaton 6y agoThat'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?
- anton96 6y agoI’m pretty sure I saw the word «webObject» in my url bar while being redirected to their site at some point.
- vhogemann 6y agohttps://en.wikipedia.org/wiki/WebObjects https://en.wikipedia.org/wiki/WebObjects
- jolux 6y agoI bet most of their Java usage is web services and not Swing client apps.
- ex3ndr 6y ago
- adamnemecek 6y agoI 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.
- WhoCaresLies 6y ago"Performance on par with OpenGL" 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..
- pdpi 6y agoThe 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”.
- WhoCaresLies 6y agoYou are right, i guess
- chrisseaton 6y agoThey'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?
- avalys 6y agoWho else uses Java Swing these days?
- madhadron 6y agoHonestly, 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.
- p1necone 6y agoWhy 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?
- threeseed 6y agoMetal is used within the OS for all of its rendering. 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.
- p1necone 6y agoI 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.
- webwielder2 6y agoStill? What would have caused them to not want to maintain control of their platform?
- p1necone 6y agoAll 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.
- webwielder2 6y agoiOS 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.
- dstaley 6y agoI 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. [1] https://github.com/KhronosGroup/MoltenVK https://github.com/KhronosGroup/MoltenVK
- bpodgursky 6y ago"Lanai" as a project name is hilarious. It's like begging to Larry Ellison "Please don't cancel the project! You'll own it all anyway!" *Lanai is the Hawaiian island that Larry Ellison owns
- akmittal 6y agoThere 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.
- Thristle 6y agoMaybe 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)
- solarkraft 6y agoAh, supporting new Platform APIs I see. It would be nice if they could start working on supporting Wayland and in turn HiDPI on modern desktops.