LINUX.ORG.RU

Сравнение сеансов GNOME на основе Wayland и X11

 , ,


1

5

Портал Phoronix провёл серию сравнений сеансов GNOME на базе Wayland и X11. Для тестов использовались дистрибутивы Fedora 27 и Ubuntu 17.10. Существенной разницы в производительности игр, энергопотреблении и объёме занятой оперативной памяти обнаружено не было.

GNOME 3.26: Wayland vs. X.Org Performance

Wayland vs. X.Org Gaming Tests

Intel Graphics Performance

anonymous

Проверено: Aceler ()
Последнее исправление: cetjs2 (всего исправлений: 4)

Ответ на: комментарий от i-rinat

Это минорная проблема, почему ее не пофиксить на уравне существующего протокола (или в новом xcb) а городить отдельный стек и ломать кучу софта ради этого ?

zaz ★★★★
()
Ответ на: комментарий от zaz

Это минорная проблема, почему ее не пофиксить на уравне существующего протокола (или в новом xcb) а городить отдельный стек и ломать кучу софта ради этого ?

Наверное, потому что никто не придумал, как её фиксить в рамках текущего протокола.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Писать такое только из-за того, что я не поддакиваю тебе, это низко и подло. А ты, соответственно, низок и подл. Это первый момент в дискуссии, когда я тоже перешёл на личности.

Не придуривайся. Ты шлангуешь с самого начала обсуждения.

Deleted
()
Ответ на: комментарий от i-rinat

Наверное, потому что никто не придумал, как её фиксить в рамках текущего протокола.

Единственное, что современные прижения делают с пикселями окна — это вызов XRenderComposite() для рисования оффскрин-пиксмапы. так сложно сделать этот вызов атомарным?

Deleted
()
Ответ на: комментарий от i-rinat

Наверное, потому что никто не придумал, как её фиксить в рамках текущего протокола.

Тоесть нереально втянуть двойную буферизацию внутрь X11 композитора и добавит команды StartDdraw / EndDraw в X11 протокол (или в его обнавленную версию XCB) ?

zaz ★★★★
()
Ответ на: комментарий от Deleted
так сложно сделать этот вызов атомарным?

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

zaz ★★★★
()
Ответ на: комментарий от zaz

Тоесть нереально втянуть двойную буферизацию внутрь X11 композитора и добавит команды StartDdraw / EndDraw в X11 протокол

Вполне реально, просто нужно же высасывать из пальца аргументы про то, что проблема не решаема.

Я выше уже написал, можно просто считать пакет композитинга окна атомарной командой. она сама себе и StartDdraw и EndDraw в одном лице.

Современеные тулкиты не рисуют промежуточные результаты в пиксели окна, они рендерят в отдельный буфер.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 2)
Ответ на: комментарий от zaz

Я не уверен, всегда ли он атомарный («это гарантируется») или в частном случае («в вашей конфигурации так получилось»).

Но если первое, тогда тем более проблема высосана из пальца.

Deleted
()
Ответ на: комментарий от sudopacman

А по теме ничего не сказал.

Буквально: зачем из Linux делать очередную паршивую ошибку с момента создания под названием Windows 7?

Lowes ★★
()
Ответ на: комментарий от Deleted

Я собственно к этому и веду, я помню тред на X.ORG когда обсуждали введение двойной буферизации в композитор, основной аргумент был такой что это не нужно и будет только хуже - так как уже тогда все основные тулкиты (gtk, qt) рендерели сами в свои битмапы и закидовали на сервер уже готовую картинку. И введение двойной буферизации на стороне X11 сервера никакого профита не даст, но увеличит накладные расходы по RAM и CPU (будет больше буферов и больше memcpy чем нужно) ...

zaz ★★★★
()
Ответ на: комментарий от Deleted

Единственное, что современные прижения делают с пикселями окна — это вызов XRenderComposite() для рисования оффскрин-пиксмапы. так сложно сделать этот вызов атомарным?

Мне как разработчику ПО как его сделать атомарным? Предлагаешь иксы пофиксить? Почему сам это не сделаешь, раз такой умный?

i-rinat ★★★★★
()
Ответ на: комментарий от Deleted

Вот API xrandr-а, вот события об изменении координат окна. Бери и реализуй любым способом, какие проблемы?

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

Мы говорим про масштабирование GUI в окне, а не окна.

Не знаю, как ты понял, но я имел в виду именно масштабирование содержимого окна как картинки. (А не изменение размеров окна, которое можно сделать, потянув мышкой за его край.)

sudopacman ★★★★★
()
Ответ на: комментарий от zaz

и добавит команды StartDdraw / EndDraw в X11 протокол (или в его обнавленную версию XCB) ?

Как вынудить приложения пользоваться этим расширением?

i-rinat ★★★★★
()
Ответ на: комментарий от sudopacman

Не знаю, как ты понял, но я имел в виду именно масштабирование содержимого окна как картинки. (А не изменение размеров окна, которое можно сделать, потянув мышкой за его край.)

Так это во всяких компизах вроде сто лет в обед. Я про то масштабирование, когда я захожу с телефона с бешеным DPI на комп, и вижу там нормальный интерфейс (т.е. по меркам монитора ноутбука — гигантский, а по меркам экрана на 5 дюймов - юзабельный).

Deleted
()
Ответ на: комментарий от Lowes

Хочешь сказать, что все обязаны пользоваться рабочими столами и не использовать несполько мониторов, а избавить владельцев ноутбуков с HiDPI от страданий при подключении внешнего монитора — это сделать из линукса винду? Или что?

sudopacman ★★★★★
()
Ответ на: комментарий от i-rinat

Мне как разработчику ПО как его сделать атомарным? Предлагаешь иксы пофиксить? Почему сам это не сделаешь, раз такой умный?

Я с самого начала разговора сказал, что вместо того чтобы фиксить иксы, красношляпа решила выкинуть их нахрен вместе с фичами.

Ты мне бодро принялся доказывать, что иксы нефиксабельны. Я в рамках такой постановки вопроса не обязан ничего фиксить, это ты обязан рассказать, как «магия» вейланда непортабельна под иксы. Сам вызвался.

Deleted
()
Ответ на: комментарий от Deleted

это ты обязан рассказать, как «магия» вейланда непортабельна под иксы. Сам вызвался.

И раза три уже рассказал и объяснил. Ты не хочешь слушать.

вместо того чтобы фиксить иксы, красношляпа решила выкинуть их нахрен вместе с фичами.

Иксы это редхат, а редхат это не иксы. Там много народу из редхата, но даже близко не большинство. Если хочешь что-то исправить, приходи в рассылку и предлагай патчи.

Пока ты это не делаешь, твои слова — простое нытьё: «они не хотят делать то, что я хотел». Хочешь починить — чини.

Лично я не представляю себе, как эта починка будет выглядеть. Ещё одно расширение? Как заставить всех его использовать?

Кстати, есть уже DBE, которое призвано как раз проблему пофиксить. Ему уже очень много лет. Но оно не работает, поэтому им никто не пользуется.

i-rinat ★★★★★
()
Последнее исправление: i-rinat (всего исправлений: 1)
Ответ на: комментарий от sudopacman

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

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

тулкиты этого не делают, нет? что-то мне кажется, что свидетелей вяленого ждут ещё новые сюрпризы.

anonymous
()
Ответ на: комментарий от i-rinat

Ещё одно расширение? Как заставить всех его использовать?

А как заставить всех использовать вэйланд?

ugoday ★★★★★
()

Учитывая, что нативно-вяленых игр нет, а все они пускаются в xwayland, т.е. получается games@x11@wayland, то результат - однозначно торт. Осталось решить две проблемы:
- завезти вяленые игры;
- показать средний палец зеленым, чтобы запилили нормальную поддержку вяленого на единственных игровых видеокартах в линуксе.

pekmop1024 ★★★★★
()
Ответ на: комментарий от Deleted

Вейланд — это иксы, из которых удалили всё, кроме композитинга битмапов

Не пори чушь.

SEInterix
()
Ответ на: комментарий от sudopacman

владельцев ноутбуков с HiDPI от страданий при подключении внешнего монитора

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

anonymous
()
Ответ на: комментарий от ugoday

А как заставить всех использовать вэйланд?

Никак.

Нужно в его рамках реализовать всё то, что нужно от графической системы. И если он будет хорош, люди сами будут переходить.

И это проще, чем внедрить использование очередного опционального расширения иксов. Кстати, знаешь, сколько их?

i-rinat ★★★★★
()
Ответ на: комментарий от anonymous

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

тулкиты этого не делают, нет? что-то мне кажется, что свидетелей вяленого ждут ещё новые сюрпризы.

Ты, похоже, не умеешь читать. Я и написал, что тулкит сам перерисует, когда ему композитор сообщит о смене DPI. А если тулкит не может перерисовать, то композитор сдеает апскейл.

sudopacman ★★★★★
()
Ответ на: комментарий от anonymous

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

Ты тоже не пори.

SEInterix
()

Низкий FPS на Wayland

На моем слабеньком(celeron b800) ноуте wayland тормозит! Что вы говорите там про тиринг? Его нет да, согласен. Но на глаз вижу, что wayland теряет кадры. Пропускает кадры когда, например, таскать окно мышкой или просто водить мышку в меню приложений. сначала удивился потому что другие дистрибутивы до этого нормально работали, но потом перезашел в xorg-режим и о чудо! Вся летает как обычно!

Что это может быть? Хотел записать скринкаст вам показать, но нативно не получается вообще все тормозит.

ult
()
Ответ на: комментарий от anonymous

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

Ты можешь нормально свои мысли выразить, а не писать какой-то бред про хакеров?

sudopacman ★★★★★
()
Ответ на: комментарий от sudopacman

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

anonymous
()
Ответ на: комментарий от SEInterix

Ты тоже не пори.

ты графики-то по первой ссылке посмотри. использование памяти +40мб на вяленом в среднем, энергопотребление +х каких-то ихних единиц в среднем.

anonymous
()

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

anonymous
()
Ответ на: комментарий от i-rinat

И раза три уже рассказал и объяснил. Ты не хочешь слушать.

«Нивазможна, патамушта да сих пор ни сделале!». Я всё правильно расслышал?

Иксы это редхат, а редхат это не иксы.

Я ничего не понял. Тут что-то с грамматикой.

Пока ты это не делаешь, твои слова — простое нытьё: «они не хотят делать то, что я хотел». Хочешь починить — чини.

Это их дело — что делать со своим кодом. А моё право — иметь мнение насчёт того, с чем я сталкиваюсь в жизни. Я уж сам как-нибудь разберусь, какой код мне писать и где.

Если мне предлагают заменить старый, гнилой, но рабочий жигуль на демоверсию скейт-борда на одном колесе («потом когда-нибудь мы добавим колеса, честно-честно!»), я не в настроении делать вид, что такое предложение вызывает у меня восторг.

Лично я не представляю себе, как эта починка будет выглядеть. Ещё одно расширение? Как заставить всех его использовать?

Невозможно всех заставить его использовать. Если в приложении нет представления об атомарном обновлении экрана, то есть всего два варианта: смириться и терпеть (возможно, используя хаки и эвристики, чтобы «подловить нужный момент»), либо отказывать ему в обслуживании. Достаточно, чтобы синхронизацию использовали qt и gtk, остальные подтянулись бы за пару лет, за исключением совсем заброшенного софта.

Лично я не представляю себе, как эта починка будет выглядеть.

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

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

Или можно возродить server-aware двойную буферизацию, которую когда-то хотели впилить. Привязывать к окну последовательность поверхностей и обновлять его содержимое командой „дождаться завершения всех поступивших операций на следующей поверхности в очереди и уведомить композитный менеджер“.

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

Deleted
()
Ответ на: комментарий от anonymous

Что-то я подустал столько лет читать одно и тоже [...] топтание на месте [...]

Это значит, что индустрия встала. Ну или обсуждаемая область по крайней мере; всякие распознавалки лиц и автопилоты для авто по слухам вполне себе развиваются.

вот и всё, что может предложить линукс и поделки к нему, увы.

Можно подумать, только линукс. Винда точно так же топчется на месте: убрали кнопку «пуск» - добавили кнопку «пуск». Про яблоки можно вообще не вспоминать - назовите 2 отличия iphone N+1 от iphone N (не помню уже чему нынче N равняется, извините).

dimgel ★★★★★
()
Ответ на: комментарий от sudopacman

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

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

anonymous
()

Вот что лично мне от вяленого надо - это чтоб список окон могло обычное окно получить, какие-то параметры любого окна типа имени, геометрии и просто связанных строк, да запросить композитор «нарисуй миниатюры тут», ну и самому к краю себя привязывать, но это вроде в desktop_shell есть.

Athor ★★
()
Ответ на: комментарий от Odalist

Так же, как заставили использовать systemd.

Шурик, насилие — не наш метод.

ugoday ★★★★★
()
Ответ на: комментарий от i-rinat

И это проще, чем внедрить использование очередного опционального расширения иксов.

что-то десятый год пошёл, а всё никак.

ugoday ★★★★★
()
Ответ на: комментарий от Deleted

И раза три уже рассказал и объяснил. Ты не хочешь слушать.

«Нивазможна, патамушта да сих пор ни сделале!». Я всё правильно расслышал?

Перестань в уши долбиться, и, возможно, слух восстановится. Но в общих чертах, да. Судя по тому объему, который всё-таки сделали, там руки из того места растут. Так что тот факт, что с тирингом кардинально проблему не решили, уже о чём-то говорит.

Ты занимаешься разработкой иксов? Если нет, почему твои слова более весомые, чем слова тех, кто занимается? Или ты настолько умный, что без знакомства с кодовой базой разбираешься в ней лучше?

Я ничего не понял. Тут что-то с грамматикой.

Я пропустил «не»: «Иксы это не редхат, а редхат это не иксы». Другими словами, они не тождественны.

Это их дело — что делать со своим кодом. А моё право — иметь мнение насчёт того, с чем я сталкиваюсь в жизни.

Пока это их код, твоё мнение ровным счётом ничего не значит. Причём это не твой, а их код не потому что кодом владеет корпорация. Это потому, что ты не хочешь кодом владеть. Никто не запрещает тебе разработкой иксов заниматься.

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

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

Ты просто из лагеря тех, кому не нравится Wayland просто потому что он есть, и ты мечтаешь запретить другим им пользоваться. Иными словами, ты вахтёр. Смирись с этим.

i-rinat ★★★★★
()
Ответ на: комментарий от anonymous

Тулкиты поддерживают масштабирование. Но в иксах нельзя сделать так, чтобы при перемещении между мониторами это масштабирование автоматически менялось.

sudopacman ★★★★★
()

Посмотрел, не сильно вдаваясь в детали правда, критику X11. Занятная ситуация получается.

Часть недостатков связана чисто с количественным отставанием X11 от современных технических возможностей и возросших потребностей. Ну т.е. элемантарно размеры различных типов данных, выделенных под хранение некоторых параметров, становятся недостаточными.

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

Есть, правда, и архитектурные недостатки. Но опять же, что удивительно, часто для их устранения предлагаются реальные решения.

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

zloy_starper ★★★
()
Ответ на: комментарий от Deleted

> Тиринг под композитором фактически возникает не из-за перерисовки окна, а из-за перерисовки экрана. Возьми окно мышкой и потаскай. Если вывод подвержен тирингу, увидишь, как оно двигается частями.

Возможно что он тоже прав. GNOME2, Compiz 0.8.8, VSync в nvidia-settings выключен, VSync в CCSM включен, Unredirect fullscreen выключен. Тиринга нет. Но я установил Gens (официальный пакет с Sourceforge) и запустил Lion King. Во время поездки на страусе (не быстрой и не медленной) возник не тиринг, но картинка двигалась рывками.

Могу заснять, если интересно. Или попробуйте воспроизвести.

Я проверял настройки эмулятора: OpenGL включен, VSync выключен, Frameskip 0. Возможно, комп не тянет 60 FPS в этом эмуляторе, а выдаёт, например, 55 FPS. И поэтому дёргается. Хотя эмулятор Денди 50 FPS нормально выводит, и ничего не дёргается.

ZenitharChampion ★★★★★
()
Ответ на: комментарий от anonymous

если в теме про hidpi упоминается апскейл, то это значит,

У вас делитанский подход к HDPI, апскейл есть у всех (и у винды и у мака) на HDPI железе. Вы никогда не задумывались о том что вот я купил HDPI монитор и у меня есть древний бинарник (приложение) которое я регулярно использую но оно написано на тулките (том же gtk2) который HDPI не супортит и никогда не будет, что мне делать в этом случае ?

zaz ★★★★
()
Ответ на: комментарий от sudopacman

Тулкиты поддерживают масштабирование. Но в иксах нельзя сделать так, чтобы при перемещении между мониторами это масштабирование автоматически менялось.

И какая же это волшебная сила мешает это делать тулкитам (которые поддерживают масштабирование) в иксах? Наверное, та же, что волжшебным образом это делает в вяленом? Не надоело уже по десять раз одну и ту же ерунду писать?

zloy_starper ★★★
()
Ответ на: комментарий от ZenitharChampion

Тиринг под композитором фактически возникает не из-за перерисовки окна, а из-за перерисовки экрана. Возьми окно мышкой и потаскай. Если вывод подвержен тирингу, увидишь, как оно двигается частями.

Именно по этой причине во многих играх в настройках OpenGL/DirectX можно выбрать Double Buffer / Triple Buffer - второй добовляет небольшой оверхед но гарантировано избавляет от тиринга

zaz ★★★★
()
Ответ на: комментарий от zaz

Я как-то врубил Compiz, и у меня все игры стали рывками. Оказалось что в CCSM (конфигуратор Compiz) включен VSync, в nvidia-settings включен VSync, и в настройках игры включен VSync. Сколько FPS я получил, интересно, 15? Нет, тройная буферизация не нужна. Нужна только двойная, 60 FPS.

Раньше от этого избавляла настройка Unredirect Fullscreen Windows: когда ты включил VSync в настройках игры, то никакой другой VSync больше не применяется - Compiz на время игры отключается. Но эта настройка работает только в тех играх, в которых не работает Alt-Tab. На тех же, на которых работает Alt-Tab, это не работает. Потому что в представлении иксов это - окно без рамки, а не полноэкранное приложение. До 2013 года таких игр вообще не было, и все игры были полноэкранными. После - примерно 100% новых игр стали выпускаться такими: окно без рамки на весь экран. Поэтому настройка Unredirect Fullscreen Windows больше не нужна, и её необходимо отключить. Она не работает.

ZenitharChampion ★★★★★
()
Последнее исправление: ZenitharChampion (всего исправлений: 9)
Ответ на: комментарий от sudopacman

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

Lowes ★★
()
Ответ на: комментарий от zaz

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

требование апскейла для hidpi - это всегда фейспалм. и нет, апскейл старого приложения - это не поддержка hidpi, это просто апскейл старого приложения на новом дисплее.

что характерно, те кто с этим хоть раз сталкивался, не кукарекают про скейл фактор, а сразу ищут device independent pixels. что ещё характерно, если дип хоть раз найти, то всё сразу станет ясно и понятно.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.