Graphics for the JVM

Let’s say I want to create quality desktop applications. I also want to do this in JVM. Don’t get your hopes up – we haven’t reached our goal yet But I have a plan.

Why JVM?

This is performance at a fairly high level, but does not force you to think too much about each memory allocation. It’s cross-platform. It has great languages ​​- Kotlin, Scala and, of course, Clojure. C # is fine too, but it doesn’t include Clojure.

Can’t you already create JVM desktop applications?

You can. But traditionally AWT, Swing, and JavaFX have come with many quality and performance disadvantages. They were so significant that only one company managed to create decent looking Swing app… It is possible, but it takes a lot of effort.

Aren’t all Java UIs cursed?

No, not at all. AWT, Swing, and JavaFX all have their own problems, but these are exclusively their problems. There is no fundamental reason why it is impossible to create a high quality user interface in the JVM. It just hasn’t been done yet.

Why hasn’t it been done yet?

I think it has to do with patience. We are so used to things that can be collected in a week that no one thinks about years. And a good user interface takes years of work. This is a great commitment.

Why not Electron?

The first reason is performance. JS is a great language for building UI, but much slower than JVM. Wasm might be fast, but it implies C ++ or Rust.

The second is the DOM. It’s a terrifying collection of gimmicks that make simple things hard and hard things impossible. I have thought many times, “If I were to draw this control / layout directly, I would have finished a few hours ago.”

This means that there is a very low limit to what web applications can do in terms of performance and quality. I believe that we can and should do better.

However, Electron taught us two good things:

  • People are hungry for native apps. Nobody wants to work from the browser.
  • People don’t care if apps don’t look native to the platform as long as they look good.

Is the desktop still relevant?

I believe that it is!

I recently watched an interview between an Android developer and an iOS developer. One asked:

“Anyone still writing desktop applications?”

To which the other replied:

“I have no idea … Maybe?”

Both of them recorded it on the desktop, in a desktop application, while talking through another desktop application. Probably several other desktop applications were used for post-processing. None of them were written by magical elves or left to us by a powerful ancient civilization. The desktop may be less trendy, but only because it’s harder to sell useless crap here.

And I was on both sides. I once lived without a desk for several weeks. You get used to it, but it is certainly not ideal. Collecting and processing any information is very painful: it is difficult to select text, it is difficult to search the page, it is difficult to have multiple tabs, it is difficult to move data between applications. For example, you add an event to your calendar. You need to find the address of the event in the mail, where there is a link that opens the browser. By the time you find what you need and return it to the calendar, it is already being unloaded from memory, and all context is lost. The ability to open multiple windows at the same time is the superpower of the desktop.

Phones are great for small, fast, single-purpose tasks. They have their place, but life is much more complicated than a telephone. Many of us still need this bike for our minds.

Okay, what do you suggest?

The road to a good user interface in the JVM is a long one. We will need:

  • graphics library,
  • window / OS integration library,
  • set of user interface tools.

Today I am delighted to announce the first part of this epic quest: the graphics library. It’s called Skija and is just a bunch of bindings to the very powerful well-known Skia library. The one that Chrome, Android, Flutter, and Xamarin.

image

Like any other JVM library, it is cross-platform. It works on Windows, Linux and macOS. It’s as easy as adding a JAR file. Much easier than massaging C ++ compiler flags for days before you can compile anything. Skija will take care of the memory management for you. And the bindings are handcrafted, so they always make sense and are fun (at least as far as the Skia API allows).

What to do about it? Mainly to paint. Lines. Triangles. Rectangles. But also: curves, outlines, shapes, letters, shadows, gradients.

image

Think of it like the Canvas API. But it seems like a really advanced version. She understands color spaces, modern typography, text layout, GPU acceleration, and the like.

image

Oh, and it’s fast. Really fast. If that’s good enough for Chrome, it probably should be good enough for your application as well.

What can I do about it?

Many things! Custom libraries of UI widgets and whole toolboxes, graphs, charts, visualizations, games. For example, we played around with implementing java.awt.Graphics2D and running Swing on top of it – everything seems to be working fine.

Why release a separate graphics library? How is this useful?

I’m not a big fan of putting everything together in one place. You can never guess all the details correctly – someone will always be unhappy with a particular decision.

Independent interchangeable libraries are more flexible. Unix philosophy.

What about the rest of the puzzle pieces?

Both things are in development at JetBrains.

  • To integrate window management and OS there is Skiko… She says this is Skia for Kotlin, but she also implements windowing, events, packing and everything else. It even integrates with AWT and Swing.
  • And for the UI toolkit, there is Compose Desktop… It is a fork of Android Compose, a declarative UI framework that runs on the desktop.

But the beauty is, it doesn’t even have to be these two!

Don’t like AWT? Bring your own windows library.

Kotlin is not right for you? Use any other JVM language.

Compose is not good at handling the load? Pray for someone to write an alternative or write something of their own (sorry, but there is no good solution yet. This is just the beginning).

And of course, if you want to deploy your own window library or widget toolkit – please do so! We hope this will happen.

Finally

Skija is part of a bigger picture. Java UI progress has been blocked by poor quality Graphics2D. But everything is changing. What will come of this? Time will tell.

Please try Skija and share your opinion with us. Or maybe start using it – we would be happy if you did! Here is the link:

github.com/JetBrains/skija

November 14, 2020 Discussion on HackerNews


Cloud servers from Macleod fast and safe.

Register using the link above or by clicking on the banner and get a 10% discount for the first month of renting a server of any configuration!

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *