官宣！Wayland正式支持基于IntelliJ的IDE-育师

对于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 中得到了解决）。

也许 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 上快速运行基于软件的渲染成为可能，并且几乎不需要修改平台无关的通用代码。