有时 GUI 响应缓慢 - 或根本不响应 - 或似乎崩溃 - 但光标仍然快速响应。鼠标指针是如何工作的？

这里至少有两个单独的细节：

1. 硬件光标
2. 光标更新被刻意优先处理

1.硬件光标

第一个细节更为人所知。您可以在文档中找到它：HWCursorXorg 中的选项。

您的图形可能使用硬件光标。当硬件将像素扫描到显示器时，它会将鼠标光标覆盖在主帧缓冲区的顶部。

• 图形驱动程序中的错误可能会错误配置帧缓冲区，而不会破坏硬件光标。
• 或者配置错误的硬件光标可能会出现损坏。但您可能仍会看到损坏的光标移动并做出响应，而显示屏的其余部分似乎已损坏。
• 或者当帧缓冲区正常时，光标可能配置错误。就像在“鼠标消失”案例中一样。

1.1 软件光标

请注意，虽然硬件光标非常有用，但也有一些技术可以使软件光标更好地工作。

https://www.x.org/wiki/Development/Documentation/InputEventProcessing/

如果在软件中完成，则必须对光标进行后缓冲。每次它移动时，我们都会恢复之前的图像，将窗口保存在目标位置，然后将光标渲染到流中。

xorg-server-1.20.5/mi/mdispcur.c - miDCSaveUnderCursor() / miDCRestoreUnderCursor()

2. 故意优先考虑光标更新

说句公道话，游标还是比较简单的。此外，它一直在使用。这意味着当您开始耗尽内存时，光标特定的内存不太可能被换出。但还有另一个细节：

https://who-t.blogspot.com/2016/09/input-threads-in-x-server.html

以前，输入驱动程序如何将事件传递给 X 服务器有两种选择：轮询或从信号处理程序中传递。轮询只是将所有输入设备的文件描述符添加到在服务器的主循环中处理的 select(2) 循环中。这里的缺点是，如果服务器忙于渲染某些东西，您的输入会延迟到渲染完成。从历史上看，轮询主要由键盘驱动程序使用，因为它在击键延迟时并不重要。既是因为您无论如何都需要客户端渲染它们（它在忙碌时不能渲染），也可能是因为我们已经习惯了打字延迟。

信号处理程序方法通过为每个输入设备 fd 安装一个 SIGIO 处理程序并在任何输入发生时调用它来规避延迟。这有效地中断了进程，直到信号处理程序完成，而不管服务器当前忙于什么。提供即时可见光标移动的绝佳解决方案 （因此它被 evdev、synaptics、wacom 和大多数现已退休的旧版驱动程序使用）

[...]

驱动程序在信号处理程序期间将事件推送到队列中，在主循环中服务器读取并处理它们。在一个繁忙的服务器中，可能是在屏幕上执行指针运动几秒钟后，但是嘿，它仍然感觉响应。

[...]

在 libinput 出现之前，我们仍然对它非常“满意”。libinput 是一个完整的输入堆栈，期望它在信号处理程序中工作是介于乐观、受虐狂和虐待狂之间的某个地方。xf86-input-libinput 驱动程序不使用信号处理程序，其副作用是带有 libinput 的桌面在服务器忙于渲染时感觉不那么响应。

Keith Packard 介入并将服务器从信号处理程序切换到使用输入线程。或者更具体地说：主线程之上的一个输入线程。该线程控制所有输入设备的文件描述符并不断从它们读取事件。否则，它提供了与信号处理程序之前相同的功能：可见指针移动和将事件推送到事件队列中，以便主线程稍后处理它们。但是，当然，一旦你切换到线程，问题就会出现在你面前。[...] 一些有趣的比赛条件不断发生。但截至今天，我们认为大部分问题都已解决。