[Перевод] Графика для JVM
Допустим, я хочу создавать качественные десктопные приложения. Я также хочу сделать это на JVM. Не надейтесь — мы еще не достигли цели. Но у меня есть план.
Почему именно JVM?
Это производительность на достаточно высоком уровне, но не заставляет вас слишком много задумываться о каждом выделение памяти. Это кроссплатформенно. В нем есть отличные языки — Kotlin, Scala и, конечно же, Clojure. C # тоже подойдет, но в нем нет Clojure.
Разве вы уже не можете создавать десктопные приложения на JVM?
Вы можете. Но традиционно AWT, Swing и JavaFX сопровождались множеством недостатков в качестве и производительности. Они были настолько существенными, что только одной компании удалось создать прилично выглядящее приложение на Swing. Это возможно, но требует огромных усилий.
Разве не все пользовательские интерфейсы Java прокляты?
Нет, не совсем. У AWT, Swing и JavaFX есть свои проблемы, но это исключительно их проблемы. Нет фундаментальной причины, по которой невозможно создать высококачественный пользовательский интерфейс на JVM. Просто это еще не было сделано.
Почему это еще не было сделано?
Я думаю, это связано с терпением. Мы так привыкли к вещам, которые можно собрать за неделю, что никто не думает о годах. А для хорошего пользовательского интерфейса требуются годы работы. Это большое обязательство.
Почему не Electron?
Первая причина — производительность. JS — отличный язык для создания пользовательского интерфейса, но он намного медленнее, чем JVM. Wasm может быть быстрым, но подразумевает C ++ или Rust.
Второй — это модель DOM. Это ужасающая коллекция уловок, которые делают простые вещи сложными, а сложные — невозможными. Я много раз думал: «Если бы я рисовал этот элемент управления/макет напрямую, я бы закончил несколько часов назад».
Это означает, что существует очень низкий предел возможностей веб-приложений с точки зрения производительности и качества. Я считаю, что мы можем и должны добиться большего.
Однако Electron научил нас двум хорошим вещам:
- Люди жаждут нативных приложений. Никто не хочет работать из браузера.
- Людей не волнует, что приложения не выглядят нативными для платформы, если они хорошо выглядят.
Десктоп по-прежнему актуален?
Я верю, что это так!
Недавно я смотрел интервью между разработчиком Android и разработчиком iOS. Один спрашивал:
«Кто-нибудь по-прежнему пишет десктопные приложения?»
На что другой ответил:
«Понятия не имею… Может быть?»
Оба они записывали его на рабочем столе, в десктопном приложении, во время разговора через другое десктопное приложение. Вероятно, для пост-обработки использовалось несколько других десктопных приложений. Ни один из них не был написан волшебными эльфами и не оставлен нам могущественной древней цивилизацией. Рабочий стол может быть менее модным, но только потому, что здесь труднее продавать бесполезную хрень.
И я был на обеих сторонах. Однажды я жил без рабочего стола несколько недель. К этому привыкаешь, но это, конечно, не идеал. Сбор и обработка любой информации очень болезненны: сложно выделить текст, сложно выполнить поиск на странице, сложно иметь несколько вкладок, сложно перемещать данные между приложениями. Например, вы добавляете событие в календарь. Вам нужно найти адрес события в почте, где есть ссылка, открывающая браузер. К тому времени, когда вы нашли то, что вам нужно, и вернули в календарь, оно уже выгружается из памяти, и весь контекст теряется. Возможность одновременного открытия нескольких окон — это суперспособность рабочего стола.
Телефоны отлично подходят для небольших быстрых одноцелевых задач. У них есть свое место, но жизнь намного сложнее, чем телефон. Многим из нас все еще нужен этот велосипед для ума.
Хорошо, что же ты предлагаешь?
Путь к качественному пользовательскому интерфейсу на JVM — долгий. Нам понадобятся:
- графическая библиотека,
- библиотека интеграции окна / ОС,
- набор инструментов пользовательского интерфейса.
Сегодня я рад анонсировать первую часть этого эпического квеста: графическую библиотеку. Она называется Skija и представляет собой просто набор привязок к очень мощной, хорошо известной библиотеке Skia. Та, которую поддерживает Chrome, Android, Flutter и Xamarin.
Как и любая другая библиотека JVM, она кроссплатформенная. Она работает в Windows, Linux и macOS. Это так же просто, как добавить файл JAR. Намного проще, чем массировать флаги компилятора C ++ в течение нескольких дней, прежде чем вы сможете что-либо скомпилировать. Skija позаботится об управлении памятью за вас. И привязки создаются вручную, поэтому они всегда имеют смысл и доставляют удовольствие (по крайней мере, насколько позволяет Skia API).
Что с этим делать? В основном рисовать. Линии. Треугольники. Прямоугольники. Но также: кривые, контуры, формы, буквы, тени, градиенты.
Думайте об этом как о Canvas API. Но вроде бы действительно продвинутой версии. Она понимает цветовые пространства, современную типографику, макет текста, ускорение графического процессора и тому подобное.
О, и это быстро. Действительно быстро. Если этого достаточно для Chrome, вероятно, этого будет достаточно и для вашего приложения.
Что я могу с этим сделать?
Много вещей! Пользовательские библиотеки виджетов пользовательского интерфейса и целые наборы инструментов, графики, диаграммы, визуализации, игры. Например, мы поигрались с реализацией java.awt.Graphics2D и запуском Swing поверх него — похоже, все работает нормально.
Зачем выпускать отдельную графическую библиотеку? Чем это полезно?
Я не большой поклонник объединять все в одном месте. Вы никогда не сможете угадать все детали правильно — кто-то всегда будет недоволен конкретным решением.
Независимые взаимозаменяемые библиотеки более гибкие. Филосовия Unix.
Что с остальной кусочками паззла?
Обе вещи находятся в разработке в JetBrains.
- Для интеграции управления окнами и ОС есть Skiko. Она говорит, что это Skia для Kotlin, но она также реализует создание окон, события, пэкэджинг и все остальное. Она даже интегрируется с AWT и Swing.
- А для инструментария пользовательского интерфейса есть Compose Desktop. Это форк Android Compose, декларативного UI-фреймворка, работающего в среде рабочего стола.
Но прелесть в том, что это даже не обязательно эти двое!
Не нравится AWT? Принесите свою собственную библиотеку окон.
Kotlin не подходит Вам? Используйте любой другой язык JVM.
Compose плохо справляется с нагрузкой? Молитесь, чтобы кто-нибудь написал альтернативу или написал что-то свое (извините, но хорошего решения пока нет. Это еще только начало).
И, конечно, если вы хотите развернуть свою собственную библиотеку окон или набор инструментов для виджетов — пожалуйста, сделайте это! Мы надеемся, что это произойдет.
В заключение
Skija — это часть более широкой картины. Прогресс пользовательского интерфейса Java был заблокирован некачественной Graphics2D. Но все меняется. Что из этого выйдет? Время покажет.
Пожалуйста, попробуйте Skija и поделитесь с нами своим мнением. Или, может быть, начните ей пользоваться — мы были бы счастливы, если бы вы это сделали! Вот ссылка:
github.com/JetBrains/skija
14 ноября 2020 · Обсуждение на HackerNews
Облачные серверы от Маклауд быстрые и безопасные.
Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!
