IntelliJ IntelliJ IDEA JetBrains Runtime

Wayland 对基于 IntelliJ 的 IDE 的支持

Read this post in other languages:

对于基于 IntelliJ 的 IDE 的 Linux 用户,一项令人期待的进步即将到来 – 对 Wayland 显示服务器协议的支持。 这项更新将带来许多好处,包括解决古老的分数缩放问题以及在与适用于 Linux 的 Windows 子系统 (WSLg)(在底层运行 Wayland 服务器)一起使用时提升桌面集成。 虽然 Wayland 支持还远未完成,但现有功能已可供在 Wayland 上运行一些 Java Swing 和 AWT 应用程序。 在这篇博文中,我们将深入研究这些进步,并探讨这种新颖的显示服务器方式带来的一些技术挑战。

Wayland

Wayland 是一种现代显示服务器协议,旨在为图形环境提供更高效、更安全、适应性更强的架构来取代 X Window 系统。 它在许多重要领域带来新的范式,例如:

  • Wayland 不提供任何绘图基元,仅促进在屏幕上显示应用程序必须提前准备的像素。 它也不会装饰窗口,尽管部分实现旨在通过自定义协议提供帮助。
  • 它将应用程序彼此隔离并与桌面本身隔离。 没有将窗口定位在屏幕上的特定坐标的内置功能,也没有查询该位置或其他窗口的像素的方式。
  • 对于表面由人类发起的所有行为 – 例如移动窗口或将文本复制到剪贴板 – Wayland 的协议要求应用程序证明它确实代表用户行事,通常通过提供最近从 Wayland 收到的事件的指针,让服务器可以独立于客户端进行验证。
  • Wayland 协议为事务性,允许逐渐构建新状态,然后将结果作为一个整体提交,确保用户永远不会看到处于不一致状态的 UI。
  • Wayland 采用模块化设计,不同服务器可以支持各种协议,这就扩展了 Wayland 的功能以满足多种用例的需求。 不过,需要注意的是,并非所有服务器都支持同一组协议。 例如,只有五分之一的流行服务器(截至 2023 年 8 月)支持最新的 wp_fractional_scale_manager_v1 协议。

领先技术

XWayland 为不(尚未)直接与 Wayland 通信的图形应用程序提供了一条过渡路径,XWayland 是在 Wayland 会话之上运行的 X11 实现。 这是所有 Java 应用程序(包括所有 JetBrains 基于 IntelliJ 的 IDE)显示 UI 并获取鼠标和键盘输入的方式。 这种安排在大多数情况下都很有效… 除了无效的情况。

拖放、窗口切换和弹出菜单存在问题,例如,无法在窗口范围之外截图。 部分问题甚至可以在 XWayland 框架内得到解决(有些问题实际上在最新 OpenJDK 中得到了解决)。 其他问题似乎永远无法解决,特别是考虑到 X11 正迅速成为一项没有多少人愿意投资的遗留技术。

也许 XWayland 最紧迫的问题是缩放。 启用分数缩放后,“遗留”X11 应用程序渲染低于显示器的分辨率,然后由 Wayland 放大,这会使任何文本都明显模糊。 原因是应用程序没有任何方法可以告诉 X 服务器它是“HiDPI 感知型”应用程序,因此服务器必须假设最坏的情况,并通过缩放窗口像素来提供“帮助”。 不过,Wayland 确实能够告诉服务器窗口的缩放比例,因此只要切换到使用 Wayland,这就不再是问题。

挑战

然而,使 Java 对 Wayland 原生化说起来容易做起来难。 就 JDK 而言,这相当于创建一个新的 Toolkit,它几乎是与 GUI 相关的所有内容的发源地。 这包括图形、鼠标指针处理、按键转换、启动屏幕显示和输入方法提供 – 这些都必须从头开始实现。 例如,X11 工具包大约有 50,000 行 Java 和 20,000 行原生代码,其中只有一小部分可以在 Wayland 中重用。

从非常概括的角度来看,任务非常简单:API (Wayland) 和另一个 API (Java) 需要互相转换。 Wayland 有 wl_keyboard:event:key 用于按键,Java 有 KeyEvent。 Java 有 SurfaceData 类来存储窗口的像素,Wayland 有 wl_buffer,等等。 不过,这些 API 的详细信息有很大不同。 举个简单的例子,长时间按下一个键时,Wayland 服务器不会生成个别键盘事件,您只会得到一个。 然而,在这种情况下,Java 桌面子系统的其余部分期望定期接收 KeyEvent 报告,并且工具包有责任做出此类安排。

从积极的一面来看,并不是要先实现所有东西才能启动一个简单的程序。 例如,Swing 应用程序不依赖于 AWT UI 元素。 这让您能够灵活确定优先级,首先交付重要的功能,将其他功能留给以后。

另一个幸运之处在于 Java 图形子系统的巧妙设计,它从不依赖于 X11 绘图基元。 这使得在 Wayland 上快速运行基于软件的渲染成为可能,并且几乎不需要修改平台无关的通用代码。

Wayland 工具包

Wayland 工具包的开发始于与 Oracle 桌面团队的共同工作 Project Wakefield。 代码基于 OpenJDK 21。 截至 2023 年 8 月,工具包提供:

  • 基于软件的渲染。
  • 最低窗口装饰。
  • 交互式调整窗口大小和重新定位窗口,包括最大化、最小化和全屏支持。
  • 弹出窗口,包括用于顶级菜单的窗口。
  • HiDPI 和多显示器支持,包括不同的显示器缩放。
  • 鼠标和键盘,包括国际字符。

未来几个月的当务之急是:

  • 基于 Vulkan 的加速渲染。
  • 输入方法。
  • 剪贴板和拖放支持。
  • 启动屏幕。
  • 使用键盘快捷键切换窗口(鉴于 Wayland 严格的安全模式,这是一项非常复杂的工作)。

更详细的进度报告可参见项目的 wiki:https://wiki.openjdk.org/display/wakefield/Work+breakdown(定期更新)。

引领未来:Wayland 上基于 IntelliJ 的 IDE

Wayland 的架构在性能和安全性方面提供了固有优势。 避开老旧的 X11 协议的复杂性,Wayland 为应用程序与显示服务器之间的通信提供了更精简的机制。 这意味着更快的渲染速度,并降低了因 X11 的过时设计引起安全漏洞的可能性。 因此,Wayland 上运行的基于 IntelliJ 的 IDE 有望表现出更好的稳定性和响应性。

使基于 IntelliJ 的 IDE 成为 Wayland 桌面的一等公民的工作正在进行。 基于软件的渲染已经在 FPS(每秒帧数)方面提供了与当前 X11 工具包相当的性能。 当前重点是确定工具包实现中的剩余差距,使它能够维持在 Wayland 上原生运行的 IDE。

参考

本博文英文原作者:

Sue

Maxim Kartashev

image description