Comments 56
Да, без особых косяков.
Напрягает только этот баг https://bugs.freedesktop.org/show_bug.cgi?id=99235
Так VNC — это и есть X-сервер. Уйдут X-сервера, уйдёт и VNC.
Кстати, интересно, под вейланд есть аналог xpra?
Нет, конечно же нет. Вы неправомерно обобщаете одну из возможных реализаций 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 меня сильно печалит
По поводу отсутствия прозрачности, думаю, не стоит печалиться. Вроде уже что-то такое пилят. Можно на сервере гонять КОМ, который вместо экрана будет жать картинки и слать их по сети.
Через что-то с низким пингом, уже не помню точно. Иксы — они такие, скорость им почти не важна, зато важен низкий пинг, иначе начинает слоупочить (в частности, скорость прокрутки в 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 восстанавливает ее из этого буфера. Хотя изначально это затевалось для избавления от мерцания…
В принципе, пользоваться можно, но ооооочень не комфортно. Ощущения, как от игры в шутер на старом компе при 10 FPS.
При примерно таком же пинге (52) RDP с включенным RemoteFX работает ощутимо лучше. пару раз даже так графический редактор запускал для небольших манипуляций.
Завтра попробую повторить на чём-нибудь медленном
И что с коммерческими ( Стим & co ) продуктами, тоже через эмуляцию?
Я тоже не понимаю радости от постоянного и полного формирования битмапа окна.
Если окно видно на 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 просто так выключить его уже не получится.
Дополнение/Изменения/Продолжение будут ? Все таки несколько лет прошло уже.
Wayland на замену X Window System