Pull to refresh

Comments 56

И когда же это счастье придет в основные дистрибутивы линукса?
В «Федорином горе» уже давно.
Иногда менюшки не в том месте появляются.
В Х-ах с менюшками тоже какие-то траблы, они заграбастывают себе весь ввод.
Пишут пофиксили, как сейчас? Кстати, по VNC из коробки к последней Федоре на Wayland уже можно цепляться?
Странно, а я всегда считал, что композитный оконный менеджер — это тот, который рендерит во внеэкранный буфер (например, Compiz для иксов или DWM из Windows Vista+).
А мне всегда казалось, что он собирает внеэкранные буферы и рендерит в свой, уже экранный. Но я могу ошибаться.
Надо в комменты какого-нибудь разработчика под Х-ы.
Я имел ввиду отличия от обычного, но да, ваша формулировка точнее. На самом деле, иксы тут даже ни при чем, эта терминология используется во многих графических программах.
> Все крутится на медлительном синхронном Xlib, и выхлоп получается как с VNC, если не хуже.

Так VNC — это и есть X-сервер. Уйдут X-сервера, уйдёт и VNC.

Кстати, интересно, под вейланд есть аналог xpra?
Вы что-то путаете. vnc — это совсем не X-сервер. Если бы это было так, как вы бы обьяснили vnc сервера на той же винде? Или x11vnc под линукс?
Под линуксом интерфейсом vnc является x11. Приложение, которое запущено внутри vnc как бы видит x11 сервер, который так или иначе предоставляет vnc.

Нет, конечно же нет. Вы неправомерно обобщаете одну из возможных реализаций vnc сервера.
Один вариант — это шаринг текущего рабочего стола, как в винде. Этот вариант предполагает граббинг экрана, что требует как определённых привелегий для приложения, так и наличия определённого набора библиотек в системе, которые позволяют это делать.
Другой вариант, это о чём говорите вы — vnc-сервер запускается как отдельная иксовая сессия и, собственно, её и представляет — просто отрисовка идёт не на экран, а в буфер vnc-сервера. Но это вовсе не значит, что всё так работает. Нет, vnc-сервер надо запускать отдельно и специально. И сетевой протокол vnc (он называется rfb) ничего общего с х-протоколом не имеет. Vnc просто передаёт пожатые битмапы в одну сторону, а события мыши и клавиатуры в другую.

> Один вариант — это шаринг текущего рабочего стола, как в винде.

Не слишком полезный вариант. Но в винде лицензионные ограничения не дают запускать отдельные сессии — так что там понятно.

> И сетевой протокол vnc (он называется rfb) ничего общего с х-протоколом не имеет

Я этого и не говорил. Меня интересует как будет происходить общение приложений с vnc. Если отказаться от X-сервера, сможет ли vnc эмулировать вейланд?
Один вариант — это шаринг текущего рабочего стола, как в винде.
Не слишком полезный вариант

Отнюдь нет. Распространённый вариант — хелпдеск рулит машиной клиента, помогает решить проблему.


Я этого и не говорил. Меня интересует как будет происходить общение приложений с vnc. Если отказаться от X-сервера, сможет ли vnc эмулировать вейланд?

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

Сетевая прозрачность X. Да, это было-было, но прошло

Ну не знаю, ещё в прошлом году активно тыкал проброс иксов через ssh — отлично работает, скорость быстрая, прокрутка плавная, лагов нет, ни в какое сравнение с тормознутым vnc — и из-за этого отсутствие сетевой прозрачности в wayland меня сильно печалит

Не знаю, что вы запускали, но во всяких GTK сейчас иксы только для создания OpenGL-контекста используются. Весь рендер идет внутри движка, так что в сетевой прозрачности нет никакого смысла.

Именно GTK-приложения и запускал, да. Как GTK2, так и GTK3 — все летали. А вот Qt подлагивал, но, к счастью, большинство используемых мной программ используют нелагающий GTK)

А через какую сеть это было?
По поводу отсутствия прозрачности, думаю, не стоит печалиться. Вроде уже что-то такое пилят. Можно на сервере гонять КОМ, который вместо экрана будет жать картинки и слать их по сети.

Через что-то с низким пингом, уже не помню точно. Иксы — они такие, скорость им почти не важна, зато важен низкий пинг, иначе начинает слоупочить (в частности, скорость прокрутки в sublime text через сеть ниже чем на локалхосте)

скорость им почти не важна

Скорее это было так, когда использовались Х примитивы. Сейчас скорость очень даже важна, т.к. по сети летает картинка картинка.
А пинг важен, согласен.

Ну не знаю, я тоже вполне логично думал что скорость важна, однако скроллинг в gtk-приложниях абсолютно плавный даже на сетях меньше мегабита и evince рисует пдфки тоже шустро (хотя ощутимо медленнее чем на локалхосте, но на юзабельности не сказывается)

Кстати, про скроллинг интересно, может ли контент скроллируемой области кешироваться на стороне Х-сервера?
ЕМНИП, в Х11 могут быть не только окна верхнего уровня, но и вложенные в них.
Есть ли там что-то вроде viewport для окна? Т.е. чтобы контент при скроле не пересылался от клиента, а сдвигался Х-сервером, клиент бы при этом только менял координаты сдвига.

Моих знаний не хватит чтобы это проверить, я простой юзер)

Разумеется, в иксах есть дочерние окна. Можете поискать их через xwininfo. Но в современных GUI-тулкитах от этой фичи изо всех сил стараются отказаться.
Да, что-то такое слышал, но не помню, почему отказываются.

Ещё всплыл вопрос про кеширование. Заметил достаточно давно.
Если программу на GTK или QT остановить, то содержимое окна повреждается и не регенерируется (если провезти другим окном поверх окна с остановленным приложением, композитинг отключён), а у приложений из состава GNUStep содержимое окна сохранялось.
Т.е. есть какое-то кеширование на стороне сервера. Интересно, почему не везде используется?
Да, что-то такое слышал, но не помню, почему отказываются.
Там было много проблем. Прозрачность, мерцание, производительность. Если вы загляните в исходники GTK/GDK, то найдете там класс GdkWindow, который инкапсулирует некоторую область для рисования и может реагировать на внешние события (например, если провести над ним курсор). Раньше этот класс был реализован через дочерние окна иксов, сейчас есть альтернатива в виде своей реализации. Также на Wayland, если я не ошибаюсь, нету такой возможности. Win32-реализация не использует нативные дочерние окна вообще и никак, потому что там творится полный «ад и Израиль» (даже сама Microsoft с начала 2000-ых не использует «нативный» API в приложениях вроде IE или офиса, гуглите на тему «win32 windowless controls»).

Т.е. есть какое-то кеширование на стороне сервера. Интересно, почему не везде используется?
Нет, это «фишка» GTK/Qt. Там на каждую свистелку-перделку приходится по отдельному буферу, в который реально рисуется содержимое. Когда вы инвалидуете какую-то область окна, то GTK/Qt восстанавливает ее из этого буфера. Хотя изначально это затевалось для избавления от мерцания…
Просто хочу уточнить свой ответ. В иксах все-таки есть «кеш», называется «backing store». Но его почему-то никто не использует и информация о нем почти не гуглится.
Поставил сейчас на сервер (до которого 56 мсек) файловый менеджер thunar.
В принципе, пользоваться можно, но ооооочень не комфортно. Ощущения, как от игры в шутер на старом компе при 10 FPS.
При примерно таком же пинге (52) RDP с включенным RemoteFX работает ощутимо лучше. пару раз даже так графический редактор запускал для небольших манипуляций.

Завтра попробую повторить на чём-нибудь медленном

Как бы это ещё объективно замерить? Понятие комфорта у всех разное. Кому-то и за обычным монитором не комфортно, 144 Гц надо (да, это немного из другой оперы, просто как пример).

Ну я субъективно наблюдал 60фпс, и мысли не было о том что это может быть некомфортным) Завтра попутно видео запишу, там кадры посчитаю

Хех, на 3G с пингом 60-100 мс и правда тормознутенько, но жить можно. А провод с пингом до 10 мс уже вполне юзабелен и даже в гимпе что-то порисовать можно (хотя кисточка иногда отстаёт, наверно из-за скорости всего мегабит)

В локалке тыкали? Там очень важен низкий пинг, чем он выше, тем тормознутее.
Да куча решений где проброс X используется. Причём даже в железе. И когда существующие возможности хоронятся с подобным слабым аргументированием — это всегда плохо и как у классика «оно барин может и хорошо звучит»… Тоже самое и со шрифтами. Это вообще не клиентское дело, а самое что ни на есть серверное. Клиенты так «насправляются», что потом ещё 50 лет разгребать их «справления» будем.
А что с либами, на которых построены почти все X11 приложения ( gtk, qt, etc )? Они уже поддерживают Wayland или какие-то переговоры с ними идут? Или все только на уровне эмуляции X11-сервера ( какой оверхэд кстати? )
И что с коммерческими ( Стим & co ) продуктами, тоже через эмуляцию?
С разморозкой. GTK (точнее, GDK) уже давно от них не зависит. В Qt5 даже есть возможность запилить свой Wayland-сервер «из коробки».
UFO just landed and posted this here
У меня в отношении wayland'а есть одно пожелание. Сейчас я могу сказать ssh -XYC user@server и запускать на сервере приложение с рендерингом локально. Вот то же самое мне хочется и от wayland-приложений. Без запуска «локального десктопа» на сервере. Как именно оно будет сделано — дело десятое, но remote X application — пусть кривой и плохой, но всё же есть и работает в 90% случаев. Даже видео умеет играть.
Одно окно — один битмап — это грустно на самом деле. Опять будут героически решать проблемы прокрутки. Хотя ещё в древних макосях всё было сделано правильно — вывод через OpenGL, одна текстура на окно, другая на прокручиваемый контент, либо полной длинны, либо в 3-4 экрана, и потом просто меняем UV-оффсет

Я тоже не понимаю радости от постоянного и полного формирования битмапа окна.
Если окно видно на 10% (только краешек), так как на 90% перекрыто другими окнами, то зачем рендерить эти 90%, тем более если в эти 90% может входить какая-нибудь тяжёлая векторная графика (типа ГИС) или вывод видео.


Приложение бы могло не рендерить лишнее, если бы знало, что этот участок окна не виден. Но Wayland заставляет тратить лишние ресурсы и рендерить каждое окно на 100%. Поправьте, если я не прав.

Однажды юзер альт-табнется в перекрытое окно, и тут битмап сильно поможет: без него все эти тяжёлые векторы начнут перерисовываться с нуля, и первое, что увидит юзер — не вектор, а серое окно, которое будет оставаться серым, пока вектор не отрисуется — такое часто можно было наблюдать в каких-нибудь WinXP или любых иксах без композитинга. Если же битмап с готовым вектором будет, то он отобразится сразу, что сильно повышает юзерфрендли. Плюс к этому если верхнее окно двигать поверх нижнего окна, то за окном будет оставаться серый след (или в запущенных случаях след из содержимого окна), так как нижнее окно будет не успевать перерисовываться. Лично мне не жалко небольшой нагрузки на проц и память ради того, чтобы подобного не происходило.


А держать запущенное видео в фоне вообще не надо, такое окно стоит хотя бы свернуть)

Пишу к вам из 2022го года. Ваша философия привела к тому, что slack с открытым в фоне окном, в которое кто-то написал анимированный смайлик жрёт 100% одного ядра CPU.

В итоге вместо того, чтобы иногда видеть серые окна, надо теперь следить за тем, чтобы некоторые окна были свернуты. Очень юзерфрендли вышло.

Telegram приостанавливает все свои анимации, когда окно неактивно.

Wayland никак не может быть виноват в том, что разработчики Slack криворучки

Если всё так просто, то почему:

А держать запущенное видео в фоне вообще не надо, такое окно стоит хотя бы свернуть)

?

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

Всё зависит от конкретной задачи. Декодирование видео ждёт ресурсы постоянно и безостановочно, и когда его не смотрят, то, вероятно, практичнее его приостановить для экономии ресурсов, пожертвовав быстрым показом актуальной картиночки.


Аналогично, неактивные/свёрнутые игры обычно сбрасывают частоту кадров до десяти-двадцати в секунду.


Напротив, тяжёлая векторная графика — это обычно статическая картинка, она не жрёт ресурсы в фоне, и выгоднее держать отрисованный битмап в памяти, чтобы не тратить время на повторую перерисовку после Alt-Tab.


Telegram мгновенно продолжает воспроизведение анимаций с того места, на котором они были приостановлены, у него задержки при Alt-Tab нет.


Slack я не использую и не знаю, что там у него происходит — спрашивайте у его разработчиков, почему они такие криворучки)


И Wayland здесь по-прежнему абсолютно ни при чём. Поведением активных/неактивных/свёрнутых окон управляют только разработчики соответствующих приложений. Все те же самые рассуждения применяются и к Xorg, и к Windows любой версии.

Wayland навязывает 3D. Это не так, обязательна только компоновка. Об этом уже было сказано выше.

А без неё совсем никак? Дело в том, что при включенном композитинге всегда навязывается VSync, по крайней мере, из моей практики и из написанного в статье. А VSync даёт ощутимый input lag в шутерах, например. Играешь будто в киселе. Если никак нельзя его форсированно выключить, то это ставит крест на соревновательных FPS под линуксом.

Для полноэкранных окон компоновка может быть отключена.

И VSync тоже отключится? Я немного не в курсе, но вроде бы есть какое-то различие между фулскрином и borderless windowed. В Windows слышал жалобы, мол, хотим borderless, чтобы Alt+Tab был то ли быстрее, то ли безболезненнее, не помню, а на Linux для меня «настоящий» фулскрин характеризовался захватом ввода, т.е. Alt+Tab или аналог из оконного менеджера не работал. Но скорее всего, там такое же окно размером с текущее разрешение экрана, а граббинг — просто побочный эффект организации ввода в конкретной игре.


Я почему спрашиваю — сам пользуюсь Compton именно для форсирования VSync, и хотя там есть опция unredirect fullscreen windows, это не влияет на VSync, он остаётся включен. Хоткеем можно включать/выключать Compton, когда нужно отсутствие тиринга или напротив, отсутствие input lag, так что тут не проблема. Но на Wayland просто так выключить его уже не получится.

Попробую проверить как время будет. Достоверных источников не нашел, но вроде бы способ есть. Похоже, что не все display server'а это умеют.
Я так понял multiseat под ним не будет как в X?
Уже есть и по отзывам неплохо работает. В нем даже есть понятие seat, как одно из базовых, типично включает в себя монитор(ы), клавиатуру, мышь.

Дополнение/Изменения/Продолжение будут ? Все таки несколько лет прошло уже.

Sign up to leave a comment.

Articles

Change theme settings