GLM 5.3 Охуенен, давно так не орал.

Оба вопроса — на самом деле один вопрос об уровнях архитектуры. Разложу.

Все экранные системы делятся на два семейства:

**Семейство А — «пиксели летают по проводу».** X11, VNC/RFB, RDP. Есть посредник, владеющий экраном; клиенты сериализуют команды или пиксели в байтовый поток. X11 (1987, MIT) проектировался сетевепрозрачным *по сути*: сервер владеет framebuffer'ом и оконным деревом, клиенты шлют DrawLine/PutImage, ресурсы (пиксмапы, шрифты, GC) живут на сервере. VNC (1998, AT&T/ORL) — его младший брат: то же «пиксели по проводу», только тупее и универсальнее — ORL его и делали как упрощённую сетевую альтернативу X.

**Семейство Б — «ручки вместо пикселей».** Unix-сокет для событий, дескрипторы общей памяти через SCM_RIGHTS, каждый рисует в свой буфер, потребитель композитит. Wayland, Android SurfaceFlinger, DRI3, QEMU `-display dbus`.

Ваш RFB-CHAOS — семейство Б *по построению*:

| RFB-CHAOS | Wayland | |---|---| | `memfd_create` + `mmap` | `wl_shm` pool (клиент создаёт memfd) | | fd через SCM_RIGHTS | fd в `wl_shm.create_pool(fd, size)` | | 16-байтовый тик «кадр готов» | `wl_surface.damage` + `commit` | | `RENDERMODE_WHEN_DIRTY` + `requestRender()` | frame callback (пейсинг под vsync) | | QEMU=продюсер, приложение=дисплей | клиент=продюсер, композитор=дисплей |

Направления ролей совпадают точь-в-точь: QEMU в этой схеме — «wayland-клиент», Android-приложение — «композитор».

Справедливости ради, X11 может возмутиться: трюк-то старый. **MIT-SHM (1991!)** — `XShmPutImage` из SysV-сегмента, по сути ваш протокол, только shmget вместо memfd. А **DRI3 + Present (2013)** передают dma-buf через SCM_RIGHTS вплоть до direct scanout. Но это заплата поверх протокола, ядро которого — командный поток через обязательного посредника. Отсюда и мем: *когда X11 оптимизируют до предела, он превращается в Wayland*. MIT-SHM покрывает только половину вашей схемы (транспорт картинок), а модель событий, пейсинга и отсутствие третьего процесса — это уже чистый Wayland. Потому я сказал Wayland, а не X11.

И да, это симметрия для вашей саги: в первой версии демон топтал «дряхлый протокол 1998 года», а во второй — молча подменил семейство VNC на семейство Wayland, сохранив вывеску. Подмена сущности при сохранении вывески — фирменный приём.

SDL — не графическая библиотека и не протокол. Это **слой адаптации к ОС**: окно + контекст GL/Vulkan, инпут (мышь/клава/джойстик/тач), аудио, потоки, таймеры. Его смысл: один и тот же бинарник игры/эмулятора работает на Windows, Linux, macOS, Android, Switch — без единого `#ifdef`. Родился в 1998 у Сэма Лантинги в Loki Software как «DirectX для всех платформ» при портировании Windows-игр на Linux. Кстати, да: SDL — ровесник RFB, так что демон, тыкавший VNC дряхлостью, стоял рядом с ровесником.

В QEMU это видно идеально: `ui/sdl2.c` — просто один из сменных display-фронтендов, наравне с `ui/vnc.c`, `ui/spice.c`, `ui/dbus.c`, `ui/gtk.c`. Все они питаются от одного и того же console API и получают **одни и те же** dirty rects. Разница только в стоке пикселей:

- SDL — in-process: dirty rect → `SDL_UpdateTexture` → окно хоста. Без протокола, без сокета, без сериализации. - VNC — внешний протокол: dirty rect → кодировка → байтовый поток → отдельный клиент.

Отсюда «SDL vs VNC» — это не «два способа перерисовки», это **«библиотека в процессе vs протокол с внешним клиентом»**. А миф про `SDL_Flip` и полные перерисовки — из SDL 1.2 (нулевые); SDL2 с 2013-го — текстуры и GPU.

Подвох, который демон скрывает на Android: сам SDL там — это Java `SDLActivity` + `SurfaceView` + `ANativeWindow` + JNI-насос событий. «Нативный SDL» от Java не спасает — он её *прячет*. Поэтому кастомный GL-клиент действительно может обогнать SDL на Android: он тоньше. Но это победа специализированного кода над generic-библиотекой, а не победа парадигмы.

Уровневая картина целиком:

- Семейства А и Б отвечают на вопрос «как пиксели доходят до экрана». - SDL отвечает на вопрос «как одному коду работать с любой ОС». SDL живёт **над** этими системами: на Linux умеет и в X11, и в Wayland; на Android сидит на том же SurfaceFlinger-пайплайне.

Сравнивать VNC со SDL — категорийная ошибка уровня «TCP против браузера». В идеальном мире вашего хаос-протокола SDL мог бы быть *потребителем*: мапит дескриптор, грузит текстуру, показывает.

И напоследок — прецеденты, чтобы демон знал, насколько он опоздал: Wayland (2008), DRI3 (2013), Android BufferQueue (2009+), и `-display dbus` в самом QEMU (2022, GNOME Boxes): QEMU шарит framebuffer через memfd по D-Bus — буквально ваша схема, но в mainline. Сила, что вечно хочет зла, вечно изобретает то, что уже лежит в документации. 🕯