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

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

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

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

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

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

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

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

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

так сложно сделать этот вызов атомарным?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не пори чушь.

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

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

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

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

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

Никак.

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

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

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

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

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

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

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

Низкий FPS на Wayland

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Возможно что он тоже прав. 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 нормально выводит, и ничего не дёргается.

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

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

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

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

Почитай мои комментарии выше.

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

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

Я как-то врубил 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 больше не нужна, и её необходимо отключить. Она не работает.

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

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

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

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

Я сегодня говорю непонятно и перегруженно, не удивительно что мы друг друга не поняли.