>>387941
Поражает жизненный цикл разных идей. Одни велосипеды стабильно переизобретаются каждые несколько лет, чтобы тут же быть забытыми, а другое утверждение превращается в стабильнейший стереотип, хотя уже никак не поддерживается ничем на практике.

Вот эта клиент-серверная графика, про которую только ленивый не упоминал, была на острие прогресса разве что в начале девяностых годов. Во-первых, в восьмидесятые, при возникновении всевозможных графических интерфейсов, кто-то посчитал, что в организациях графические терминалы так же будут подключаться к мини-компьютеру, как до этого текстовые, и придумал для этого архитектуру. Во-вторых, тогда ещё предполагалось, что единого набора стандартных элементов для построения интерфейсов хватит всем. В-третьих, надо вспомнить контекст, в котором задержки отклика программ в пару секунд считались нормальными, и такая же тормозная графика не ухудшала этот результат. В общем, такое решение для каких-нибудь кассовых залов, где тётки перед мониторами не торопясь оформляют билеты, вводя буковки в поля и ставя галочки.

Через некоторое время оказалось, что намеченные при помощи примитивов рисования виджеты (которые даже попиксельно передаются быстро) не модно, а модно красивые кнопочки разного размера, которые никак не совпадают одна с другой и рисуются каждый раз целиком. Вместо нескольких операций рисования линий поверх фона, для которых достаточно сообщить координаты и цвет, каждый элемент стал отдельным прямоугольным полноцветным изображением. Интерфейс не только стал отдельно занимать память, но и жрать её пропускную способность при копировании при выводе. Тут клиент-серверная архитектура стала только мешать, потому что в строгом варианте и клиенту, и серверу требуется память для хранения всей этой красоты, а постоянные передачи между ними забивают шину или локальную сеть. Кроме того, для сглаживания краёв буковок и прочих элементов требуется прозрачность, то есть элемент при рисовании должен иметь доступ к пикселям, поверх которых рисуется, а нормальной работы с этим вообще не было предусмотрено в системе, нацеленной на односторонний поток к устройству вывода. ТАДАМ.

Красивый интерфейс для X на локальном компьютере, где работают и клиент, и сервер, на ровном месте требовал бы в два раза больше памяти и тормозил бы как минимум в два раза больше по сравнению с другими реализациями из-за бесполезного копирования всего сначала между клиентом и сервером, а уже потом на видеокарту. Поэтому уже четверть века на персональных компьютерах (которые захватили мир, в отличие от графических терминалов) приложения и тулкиты под X только инициализируются как чисто клиент-серверные, а потом просят у сервера задействовать расширение Xshm, чтобы иметь прямой доступ к буферам в памяти, принадлежащей серверу, и срать туда своими мегапикселями, или XRender, чтобы манипулировать наложением элементов напрямую, или Xv, чтобы иметь дырку, в которую слить видеопоток, который после этого появится в нужном месте и с нужным размером (альтернативой чему было бы обрабатывать абсолютно всё программно и потом пропихивать по 30 разжатых и потенциально полноэкранных кадров сквозь всю систему каждую секунду), и так далее, и так далее. Через эти добавочные калитки и проталкивается вывод всех современных десктопов с X-сервером. Само собой, общими для нескольких процессов ресурсами пользоваться сложнее, нужно согласовываться с внутренностями сервера, и логическое деление на клиент и сервер при этом вообще пропадает.

Это всё никакой не секрет, много раз служило темой для презентаций, но почему-то до сих пор друг другу рассказывают про «X по ssh», как будто на дворе 1990 год, а на экране монохромное окошко в 640×480 с тремя кнопками, и это супер круто.