После восьми месяцев разработки сформирован (https://lists.freedesktop.org/archives/wayland-devel/2018-Ap...) стабильный релиз протокола, механизма межпроцессного взаимодействия и библиотек Wayland 1.15, а также развиваемого параллельно композитного сервера Weston 4.0 (https://lists.freedesktop.org/archives/wayland-devel/2018-Ap...). Ветка Wayland 1.15 обратно совместима на уровне API и ABI с выпусками 1.x и кроме исправления ошибок примечательна следующими изменениями:
- Добавлен новый API wl_display_destroy_clients() для проведения чистки клиентов до разрушения связанного с ними вывода;
- Документировано применение двойной буферизации в wl_subcompositor.get_subsurface;- В wayland-scanner добавлена возможность генерации как публичных, так и приватных идентификаторов. Добавлен вывод предупреждения при попытке использования старой опции "code". Представлена новая опция "--strict", обеспечивающая мгновенное прекращение работы в случае проблем при верификации DTD;
- Функциональность библиотеки libwayland-egl включена в состав libwayland и скоро будет удалена (https://www.opennet.ru/opennews/art.shtml?num=48340) из Mesa;
- В переменной окружения WAYLAND_DISPLAY теперь допускаются только абсолютные пути.
В Weston развиваются технологии, содействующие появлению полноценной поддержки протокола Wayland в Enlightenment, GNOME, KDE и других пользовательских окружениях. Разработка Weston нацелена на предоставление высококачественной кодовой базы и рабочих примеров для использования Wayland в десктоп-окружениях и встраиваемых решениях, таких как платформы для автомобильных информационно-развлекательных систем, смартфонов, телевизоров и прочих потребительских устройств.Смена номера версии Weston на 4.0 обусловлена изменениями ABI, нарушающими совместимость, например, удалена поддержка протокола xdg-shell-v5 (оставлен только xdg-shell-v6). В новой версии Weston добавлена поддержка протокола input-timestamps, позволяющего клиентам с высокой точностью получать информацию о времени наступлений событий ввода. Добавлена базовая поддержка атомарного изменения видеорежимов.
Также представлена реализация протокола zwp_linux_dmabuf_v1, в
gl-renderer добавлена поддержка EGL-расширения fence_sync (синхронизация формирования вывода), обеспечено кэширование свойств DRM (Direct Rendering Manager).Статус поддержки Wayland в окружениях рабочего стола и дистрибутивах:
- В GNOME сеанс на базе Wayland рекомендован в качестве основного. В
композитном менеджере Mutter при использовании Wayland обеспечена (https://www.opennet.ru/opennews/art.shtml?num=48263) поддержка систем с несколькими GPU и гибридных графических подсистем (GPU Intel + GPU NVIDIA или AMD). В GNOME для Wayland реализована (https://www.opennet.ru/opennews/art.shtml?num=47100) поддержка удалённого рабочего стола;- В выпущенной компанией LG открытой платформе webOS Open Source Edition предложен (https://www.opennet.ru/opennews/art.shtml?num=48289) новый композитный менеджер, основанный на протоколе Wayland;
- В KDE продолжает наблюдаться прогресс (https://www.opennet.ru/opennews/art.shtml?num=47363) в стабилизации и расширении поддержки Wayland. KDE Plasma 5.12 стал (https://www.opennet.ru/opennews/art.shtml?num=48027) первым LTS-выпуском с поддержкой Wayland. В Kubuntu 18.04
реализован (https://www.opennet.ru/opennews/art.shtml?num=48402) экспериментальный сеанс на базе Wayland;
- В openSUSE Leap 15 будет предложен (https://www.opennet.ru/opennews/art.shtml?num=48041) сеанс KDE на базе Wayland;- Использование по умолчанию сеанса (https://www.opennet.ru/opennews/art.shtml?num=46962) на базе Wayland в Ubuntu 17.10 (https://www.opennet.ru/opennews/art.shtml?num=47417). В LTS-выпуске Ubuntu 18.04 по умолчанию будет возвращён традиционный графический стек на основе X.Org Server, а сеанс на основе Wayland предложен в качестве опции. В выпуске Ubuntu 18.10, а также в следующем LTS релизе Ubuntu 20.04, планируется вернуться на использование Wayland по умолчанию;
- Продолжатся работа по улучшению поддержки Wayland в Enlightenment (https://www.opennet.ru/opennews/art.shtml?num=47494). В версии 0.22 добавлена поддержка протокола xdg-shell v6, ограничений движения указателя и протокола для относительного позиционирования указателя, а также улучшена поддержка XWayland и повышена стабильность работы под управлением Wayland;- В медиаплеере VLC 3.0.0 представлена (https://www.opennet.ru/opennews/art.shtml?num=48049) начальная поддержка Wayland;
- В дисплейном сервере Mir обеспечена (https://www.opennet.ru/opennews/art.shtml?num=47378) поддержка работы клиентов Wayland, что позволяет организовать запуск Wayland-приложений в окружении Mir, используя Mir в качестве композитного сервера для Wayland;
- Система вывода в механизме для запуска виртуальных машин с Linux в ChromeOS предоставляет (https://www.opennet.ru/opennews/art.shtml?num=48146) встроенную поддержку Wayland-клиентов (virtio-wayland) с выполнением композитного сервера на стороне основного хоста и возможностью эффективного использования GPU из гостевых систем;
- Развиваемая проектом Qt платформ для автомобильных систем Qt Automotive Suite включает (https://www.opennet.ru/opennews/art.shtml?num=48157) Qt Wayland Compositor, многопоточную систему отрисовки для встраиваемых устройств, использующую протокол Wayland;
- Fedora 27 (https://www.opennet.ru/opennews/art.shtml?num=47566) стал третим выпуском, в котором по умолчанию предложен сеанс GNOME на базе Wayland;- Для FreeBSD подготовлены (https://www.opennet.ru/opennews/art.shtml?num=46829) порты, необходимые для сборки KDE с поддержкой Wayland;
- Использующие Wayland пользовательские окружения papyros-shell (http://papyros.io/) и Hawaii (https://www.opennet.ru/opennews/art.shtml?num=38730) объединились в новый проект Liri (https://liri.io/). Liri базируется на Qt 5 (QML) и продвигает оформление в стиле Material Design. Рабочий стол развивается командой дистрибутива LiriOS, примечательного использованием вместо традиционных пакетов готовых системных срезов на основе технологии OSTree, при которой системный образ атомарно обновляется из Git-подобного хранилища, позволяющего применять методы версионного контроля к компонентам дистрибутива;
- В ОС DragonFly BSD развивается (https://www.opennet.ru/opennews/art.shtml?num=43138) порт с Wayland и Weston, имеется (http://lists.dragonflybsd.org/pipermail/users/2016-May/24962...) поддержка XWayland;
- Wayland задействован по умолчанию в мобильных платформах Plasma Mobile (https://www.opennet.ru/opennews/art.shtml?num=42668), Sailfish 2 (https://www.opennet.ru/opennews/art.shtml?num=42944) и Tizen (https://www.opennet.ru/opennews/art.shtml?num=42978).- В панели Cairo-Dock предусмотрена (https://www.opennet.ru/opennews/art.shtml?num=40906) возможность работы в окружении композитного сервера Weston.
- В рамках проекта AsteroidOS развивается (https://www.opennet.ru/opennews/art.shtml?num=45640) новая открытая ОС для умных часов, использующая Qt5 и Wayland;
- Работа по добавлению поддержки Wayland ведётся для рабочих столов LXQt (https://www.opennet.ru/opennews/art.shtml?num=41633) и MATE (https://www.opennet.ru/opennews/art.shtml?num=39106).- Развивается десктоп-окружение Orbital (https://www.opennet.ru/opennews/art.shtml?num=38934), работающее только на базе технологий Wayland;
- Для тестирования работы GNOME, KDE и Enlightenment, Hawai и Orbital поверх Wayland выпускается (https://www.opennet.ru/opennews/art.shtml?num=43837) специальный Live-дистрибутив Rebecca Black Linux (http://sourceforge.net/projects/rebeccablackos/).
Напомним, что Wayland представляет (http://wayland.freedesktop.org/architecture.html) собой протокол взаимодействия композитного сервера и работающих с ним приложений. Клиенты самостоятельно ...
URL: https://lists.freedesktop.org/archives/wayland-devel/2018-Ap...
Новость: https://www.opennet.ru/opennews/art.shtml?num=48418
Ситуация с Wayland+Nvidia drivers печалит.
И раньше тоже к GNU/Linux выбирали видеокарту, а не наоборот, конечно, это делают те, кто сознательно и давно пересел.
Еще лет 10 разработки и "золотой ключик у нас в кармане".
Если нвидия не изменит свои подходы, то всегда будет в догоняющих и это будет бесконечность, а не 10. Потому что пока они там фигачат в своей норке - остальные могут уйти. И не обязательно в ту сторону которую ожидала нвидия. Что случается с нвидией дальше - думаю понятно. Дрова начинают работать с кучей "если".
>Если нвидия не изменит свои подходы, то всегда будет в догоняющих и это будет бесконечность, а не 10Если линукс не изменит свои подходы, то всегда будет в догоняющих и это будет бесконечность, а не 10.
Я за тебя исправил, не благодари. А вот нвидия - лидер с больше 60% рынка и самыми нормальными картами в реальной жизни, а не твоих влажных фантазиях.
>Если линукс не изменит свои подходыИ какие же именно он подходы должен, по вашему, изменить?
>>Если линукс не изменит свои подходы
> И какие же именно он подходы должен, по вашему, изменить?Прежде всего, выработать единый стандарт, а не базарный способ разработки, при котором в начале выпускается годный продукт, в середине что-то кого-то не устраивает и они этот продукт форкают продолжая параллельно развивать рядом, а в конце нормальные разработчики охеревают и отказываются поддерживать этот зоопарк.
Ты не мог не заметить, что вопреки воплям задpотов, ВСЕ что выпускается Леней и Редхатом лично - работает (как - другой вопрос), но работает слаженно, стандартизированно, отлично, совместимо. До pulseadio к примеру, работа со звуком была сущим адом. Даже банальная регулировка громкости каналов, не говоря уже о выводе звука в наушники при их подключении, или в блютуз гарнитуру с возможностью выбора двумя кликами. Удобство - именно благодаря отсутствию форков.
> Прежде всего, выработать единый стандартЕдиный стандарт чего?
И зачем?
И где он, единый стандарт, есть?> Ты не мог не заметить, что вопреки воплям задpотов, ВСЕ что выпускается
> Леней и Редхатом лично - работает (как - другой вопрос), но
> работает слаженно, стандартизированно, отлично, совместимо.Вообще-то нет.
>До pulseadio к примеру
До pulseaudio, к примеру, звук просто работает. теперь он просто работает после сноса этого хлама.
В общем, так себе пример. Такие стандарты нам не нужны.
> Единый стандарт чего?
> И зачем?
> И где он, единый стандарт, есть?И главное - что мешает тем кто хотел винду 1 в 1 просто пойти и купить винду? Смысл копировать винду 1 в 1 все-таки равен нулю.
И как угодно но кернелмод линя равзивается намного лучше виндового. А раз так - нет повода чинить то что не сломано. Если кому не нравится как работает эта команда, не пользуйтесь их продуктом. Они себя не навязывают. А много кому вот нравится. Включая даже корпорации с мировыми именами. Так что может ну его нафиг - следовать советам каких-то умников? Особенно без понимания обоснования.
> До pulseaudio, к примеру, звук просто работает.
Вот тут можно поспорить. Таки апи у алсучки довольно поганое а многие довольно критичные вещи - опциональны. Что обрекает кодеров на кодинг fallback path с своей реализацией всяких микшеров и ресэмплеров, на случай если этого не окажется. А вот это апликушнику среднего пошиба нафиг не надо. Это извините меня большая и крутая экскурсия в обработку сигналов и много новых знаний. Явно лишних для "хочу пробухтеть анонс мессаги в чате" и проч. Поэтому половина апликушников на алсу положили и у них были к тому веские причины.
А то что алсу костылями можно научить мимикрировать под пульс с нормальными апи - вот скажите, а почему нельзя было просто взять и сделать нормальное апи? И потребовалось делать вот это и вот так? Разработчики алсы такие крокодилы что с ними договориться нельзя? Или они вымерли? Честно говоря это для меня до сих пор некая загадка.
> Единый стандарт чего?
> И зачем?По всей видимости "всего". =)
А на самом деле, для разработки нужны, как минимум, техническая документация, стандартизированное неизменное API и продуманная архитектура, а желательно еще и некоторое готовое SDK.
Это важно для ускорения и удешевления процесса разработки нового софта.> И где он, единый стандарт, есть?
Например в ядре Linux есть, в Android есть, но не в ОС Linux в целом. Зоопарк дистрибутивов с их "особенностями" делает разработку ПО дороже. Из прикладного ПО более-менее целесообразно разрабатывать разве что что-то на базе Electron, java всех мастей и прочее пытающееся отделиться от особенностей ОС, потому что релиз для линукса - катастрофа. Речь идёт о собственном корпоративном софте, опять же, а не об открытых проектах которые предоставляются широкой массе пользователей под правильными лицензиями и теоретически могут попасть в репозиторий, если его кто-то будет сопровождать. "Сопровождать" - пересобирать, учитывая особенности обновления особенностей конкретного дистрибутива.
> В общем, так себе пример. Такие стандарты нам не нужны.
Как, в принципе, и все дистрибутивы Linux при разработке прикладного софта для собственных пользователей. Проще его не использовать. Разработка под workstation на linux обычно не просто дороже чем на другие ОС, она дороже с учётом стоимости покупки других ОС. RedHat/CentOS/Oracle Linux в этом конкретном случае - луч света тёмном царстве админов, рассуждающих о ненужностях. "Такие стандарты нам не нужны."... держите нас в курсе, а нам стандарты нужны.
А что, собственно, запрещает ту же пульсу форкнуть? Ну, кроме того, что пилить это овнище нафик никому не сдалось?
> А что, собственно, запрещает ту же пульсу форкнуть? Ну, кроме того, что
> пилить это овнище нафик никому не сдалось?То что кроме форкнущего, ЭТО больше никто не сможет поддерживать, как и никто не будет ЭТИМ пользоваться. Ну разве что случится чудо, и форк будет лучше своего родителя, что учитывая кpасноглазые тенденции запиливать лабуду которой 99% не пользуются (вроде сетевой поддержки в X-сервере) - вряд ли.
> что учитывая кpасноглaзые тенденции запиливать лабуду которой 99% не пользуются (вроде сетевой поддержки в X-сервере) - вряд ли.Ценно ли сие оналитическое мнение?
Учитывая тенденции опеннетных оналитегов писать лабуду, называя MITовцев, DECовцев и IBMщиков крacноглaзиками, да еще и с какими-то циферками от балды - вряд ли.
>работаетПуса скажем работает только когда она работает, но даже в том не заслуга Лены. Она может либо работать, либо не работать, либо всё вместе. И это, на минуточку, уже 15 лет её пишут. По-моему, ты бредишь. Ну и как всегда концептуальные недостатки у всего.
>слаженно, стандартизированно, отлично, совместимоэто явно не про линукс и даже не про венду. Что у нас остаётся? Макос? Ну, отчасти правда. Но и там всё то же самое.
> Если линукс не изменит свои подходы, то всегда будет в догоняющих и
> это будет бесконечность, а не 10.Догоняющих кого? Где? И почему? А, ты про стагнирующий рынок десктопов и ноутов который на ладан дышит? И который даже MS уже не возбуждает?
> Я за тебя исправил, не благодари. А вот нвидия - лидер с
> больше 60% рынка и самыми нормальными картами в реальной жизни, а
> не твоих влажных фантазиях.Пардон, 60% какого именно рынка? Загибающихся десктопов, на котором производство dGPU вообще едва себя окупает? Вот сейчас все $%^нутся и побегут рубаться за этот сегмент рынка насмерть, да еще раздвигая в процессе ноги под каку-то нвидию. А эта самая нвидия интересно не боится доиграться таким манером? А то у нее в отличие от амд и интеля - интеграта нет и толком не предвидится. Ну то-есть тегры есть, но они в маздае не работают, а в линухе нвидии фак показывают и тегры в целом далеки от оглушительной популярности. И как-то так получается что по мере роста интеграции... нвидии нечем конкурентов крыть. В смысле, тегра с такой политикой относительно линя - это несерьезно. А маздай на теграх вообще не работает.
Где она печалит-то? Я пользуюсь Fedora + NVIDIA, гном работает
На nouveau или на проприетарных?
Я пользовался на проприетарных. Гном то работает, но в играх производительность гораздо хуже под Wayland. Так что пока я опять на иксах.
Ну это там, а на открытых как раз наоборот. Только расстраивает отсутствие tearfree в вяленом.
Тю, а на ЛОРе кричат, что наоборот, в Wayland tearfree во все поля :(
На Intel и Amd ничего не рвётся, да.
> На Intel и Amd ничего не рвётся, да.Ну так они DRM/KMS из ядра линуха юзают. А нвидия накорябала свое эрзац-глюкало сама как умела. И работает оно понятно как. Разработчики линя себе и своим коллегам подыгрывают там и тут. А нвидия тихо, сама с собою, правою рукою. В своей норке.
Поэтому интеграция нвидии с системой - УГ. И таковым останется, пока до нвидии не допрет что ее блобы разработчикам сильно похрен.
>> На Intel и Amd ничего не рвётся, да.
> Ну так они DRM/KMS из ядра линуха юзают.Который сам штеуд и пропихнул. Правда, с целью получить преимущество перед другими, а не принести свет и благо для всех, "подыгрывая коллегам".
А получив, потихоньку забил и на ядерную часть - "да GPU Hung с вами, чините добавкой 'noaccel true' в иксах". И на иксовую - вон, дебиан c бубунтой еще почти два года назад перешли на modesetting вместо intel-video. Видимо, чтобы не скучно было или потому что тайные хейтеры.
> Разработчики штеуда себе и своим коллегам подыгрывают там и тут.
> Поэтому интеграция нвидии с системой - УГ. Штеуда - чуть менее яркое и резкое УГ, но фанаты этого в упор не замечают.Поправил, не стоит благодарности.
> Который сам штеуд и пропихнул.И между нами, ИМХО, это лучшее что штеуд сделал в софтостроени за всю свою историю. По крайней мере это логичная продуманная подсистема, учитывающая существование самых разных вариантов хардвара, даже довольно эзотерических и вообше совсем не похожих на интелский хардвар. Так что какой-нибудь HDMI выхлоп у рокчипа неплохо вписывается в это. Казалось бы, какое дело интелу до китайского проца за 5 баксов? А поди ж ты, из-за интеля удобно и какой-то мелкой китайской фирмочке. Которая пилит себе драйверок. И кодить им пришлось в разы меньше чем если бы KMS/DRM не было.
> Правда, с целью получить преимущество перед другими, а не принести свет и благо для всех,
Я бы попросил какой-нибудь внятный пруф на этот счет.
> "подыгрывая коллегам".
Вообще-то весь опенсорц - об этом. Чтобы сформировать некое совместно развиваемое core технологий. Конкурировать это не мешает. И снижает косты на разработку. Всем!
Это не самоцель, НО если этого подыгрыша не будет - карты не лягут и ничего не получится, процесс не запустится. Будет как с проприентарными бсд, где каждый тащит в свою норку, а в целом все разваливается на дюжину проприетарных недоносков где каждый жмется в своей норке мелкой жабой.
> А получив, потихоньку забил и на ядерную часть -
На твое несчастье я таки читаю логи коммитов в майнлайн и помню ключевых персон из интеля. И поэтому ответственно заявляю: наглое вранье. Коммитят аки черти. Каждый релиз ядра.
Как угодно но народ из интеля в этой подсистеме весьма активен и до сих пор важные фигуры в становлении и развитии подсистемы. И таки знаешь, даже какой-нибудь "интелский" Daniel Vetter был горой за SimpleDRM для мелочи. Хоть конкретно интелу с этой инициативы вроде и не перепадает никаких очевидных дивидендов. Это не очередной бот, а таки полноценная личность, со своими интересами к подсистеме, за что и нанят в интель видимо. Такого народа в интеле попадается. Видимо, они все-же усвоили что нанимать пофигистичных биороботов и давиться мелочной жабой - субоптимально.
> "да GPU Hung с вами, чините добавкой 'noaccel true' в иксах". И на иксовую
> - вон, дебиан c бубунтой еще почти два года назад перешли
> на modesetting вместо intel-video.Если бы кто-то хоть немного реально интересовался подсистемой, то знал бы что в иксах вообще адовое месиво. А ты думаешь чего все так на вэйланд хотят? Если б трындец был только у интеля я бы это понял. Но трындец там везде. АМД вон вообще не стали для GCN 2D ускорение кодить, решив что это себе дороже и завернули все через 3D.
Называя вещи своими именами, с точки зрения глобальной оценки активности иксы - черная дыра для человекочасов. Вбухивать можно невероятную прорву усилий а результата будет мало.
> Видимо, чтобы не скучно было или потому что тайные хейтеры.
Как ни странно, хотя я не фанат интеля, но очень позитивно воспринимаю некоторых рож оттуда. Оин делают круто хорошо и правильно и развивают Linux в целом, а не только свою норку. Это и есть норамальная здоровая опенсорсная экосистема.
> Поправил, не стоит благодарности.
Выбирая между интеграцией от амд/интеля и нвидией - без вариантов. Да что там, даже пятибаксовый китайский рокчип может оказаться в целом лучше с точки зрения общего UX с системой. Потому что даже эта китайская фигня будет плевать графику на монитор без камасутры характерной для нвидии, представляешь? И у них не отвалится драйвер из-за новой версии ядра. И условий по либам, иксам и проч они в стиле нвидии не будут выдавать.
Так что нет. Таких ушлепанов как нвидия в линуксе по счастью остается все меньше. А если нвидия хочет чтобы им было удобно - надо принимать участие в создании core, а не пилить какую-то НЕХ в своей норке приватно. В линухе - вот так.
>> Правда, с целью получить преимущество перед другими, а не принести свет и благо для всех,
> Я бы попросил какой-нибудь внятный пруф на этот счет.Пруфы, что политика компании интель не направлена на "благотворительность"? Или что отвественные за решение не расчитывали как-то подвинуть невидию с амдами/ати хотя бы на некоторое время? Серьезно?
Посмотри дрова от интеля для других системных компонентов от интеля, что ли. То густо, то пусто, по принципу "кое-как работает, значит вам сойдет" – сильно в зависимости от выгоды^W интереса.
https://www.opennet.ru/opennews/art.shtml?num=44244
> Проблемы с управлением питанием процессоров Intel Skylake в Linux
> При использовании Linux такие ноутбуки потребляют на 40% больше энергии,
> Проблему может решить только компания Intel, так как документация по управлению питанием Skylake не опубликована и независимые разработчики ядра не могут самостоятельно подготовить патч.
>> "подыгрывая коллегам".
> Вообще-то весь опенсорц - об этом. Чтобы сформировать некое совместно развиваемое core
> технологий. Конкурировать это не мешает. И снижает косты на разработку. Всем!Вообще-то кавычки используются не просто так (хинт: cлово в кавычках может иметь несколько иное значение, например - ироническое).
>> А получив, потихоньку забил и на ядерную часть -
> На твое несчастье я таки читаю логи коммитов в майнлайн и помню
> ключевых персон из интеля. И поэтому ответственно заявляю: наглое вранье. Коммитят аки черти. Каждый релиз ядра.На твое несчастье, я таки имею наглость действительно пользоваться этим и регулярно, в течении нескольких лет поглядывал в списки рассылок, багтрекеры и просто обмен опытом других таких же пользователей, поэтому ответственно заявляю: наглая маркетология и не менее наглое вранье про вранье!
Первые i-коры кое-как, починили где-то в 2015 году. "Спасибки" (хинт: здесь cлово в кавычках имеет ироническое значение), но толку от их суеты и "коммитов аки черти"?
Для более новых, из того что гуглится сразу: https://bugs.freedesktop.org/show_bug.cgi?id=62373 - это характерно и показательно, если ты "не угадал" при покупке.
С самыми новыми - ну зафигарь "GPU hang intel" в любимый поисковик, что ли. Если грубо, то пользоваться можно начинать где-то два, два с половиной года после релиза железяки.
Вы что, действительно считаете это tier1, поддержкой первого класса, достойной ваших многочисленных, пространных и хвалебных од интелю?
>> "да GPU Hung с вами, чините добавкой 'noaccel true' в иксах". И на иксовую
>> - вон, дебиан c бубунтой еще почти два года назад перешли
>> на modesetting вместо intel-video.
> Если бы кто-то хоть немного реально интересовался подсистемой, то знал бы что
> в иксах вообще адовое месиво. А ты думаешь чего все так на вэйланд хотят? Если б трындец был только у интеля я бы это понял. Но трындец там везде. АМД вон вообще не стали для GCN 2D ускорение кодить, решив что это себе дороже и завернули все через 3D.Если бы кто-то хоть немного реально интересовался подсистемой или умел в чтение, а не выглядывание знакомых слов, то знал бы, что "noaccel true" в иксах отключает аппаратное ускорение полностью. Вот этим (как и отключением RC6) "лечили" (и лечат) GPU-hung. Что оно медленное и жрет ЦПУ, можно наверное не упоминать. И о том, что о 3D в такой системе можно будет забыть, тоже.
> Называя вещи своими именами, с точки зрения глобальной оценки активности иксы -
> черная дыра для человекочасов. Вбухивать можно невероятную прорву усилий а результата будет мало.Называя вещи своими именами, с точки зрения пользователя, никакая чорная дыра в юзерспейсе не должна приводить к подвешививанию графики в ядре. Потому что все рендерить через ЦПУ медленно, жрет батарейку и совсем не справляется с нагрузкой.
>> Видимо, чтобы не скучно было или потому что тайные хейтеры.
> Как ни странно, хотя я не фанат интеля,Если судить по хвалебным одам и агрессивной защите, я бы с этим не согласился.
>> Поправил, не стоит благодарности.
> Выбирая между интеграцией от амд/интеля и нвидией - без вариантов.[]
> Так что нет. Таких ушлепанов как нвидия в линуксе по счастью остается
> все меньше. А если нвидия хочет чтобы им было удобно -Мне вот интересно, с чего ты решил, что я "за невидию"? Может, я из тех, кто выбирая между сортов "этого самого", не спешит начинать восхвалять свой выбор, как экзотический вид шоколада?
> Или что отвественные за решение не расчитывали как-то подвинуть невидию с амдами/ати хотя бы
> на некоторое время? Серьезно?Ну хотя-бы вот это, да. И ты знаешь, глядя на то что творилось с UMS и проприетарными дровами - я только за то чтобы их не то что подвинули, а выпнули нафиг за такое непотребство. Можно вместе с рухлядью типа иксов. Я помню как все это работало и это совсем не то как должна работать графика по моему пониманию.
До амд пинок более-менее дошел и, черт возьми, пошел им очень на пользу. И глядя на результат - жаль что интел на 5 лет раньше такого пинка не врезали. А надо бы было. И таки дошло не на 100%. А только на 85%. Но прогресс весьма радует глаз - получился нормальный кондовый вендор, который уже усвоил как правильно делать поддержку своего железа в лине. И остальные почти все это более-менее подусвоили. Ну вот кроме нвидии - в семье не без урода.
> Посмотри дрова от интеля для других системных компонентов от интеля, что ли.
> То густо, то пусто, по принципу "кое-как работает, значит вам сойдет"
> – сильно в зависимости от выгоды^W интереса.Там конечно варьируется, НО в целом основная проблема интеля на самом деле в том что их железо GPU по железу полный трэш. Кривой, забагованный, тормозной, и все настолько плохо что иногда даже HW team не может сказать дровописакам какого хрена оно глючит и виснет. И затыкание этого требует от тимы героических усилий. А они еще порасплодили с чуть не дюжину версий хардвара чтобы совсем зашибись. И вот команда дровописак геройствует пытаясь выправить факапы HW team. Это значительно суровее чем то что творится у АМДшников. Как у нвидии - не знаю, они драйвер в норке пилят и мне не видно. Да и не интересно.
В результате я думаю что они зашиваются телепаясь между затыканиям факапов HW team и кучей версий хардвара и даже большая команда начинает буксовать. В меру моего понимания основные лавры за эти достижения принадлежат HW team. Видимо радеоны они лицензировали у амд не от хорошей жизни, а потому что отчаялись догнать свои собственные GPU до приличного состояния.
> Вообще-то кавычки используются не просто так (хинт: cлово в кавычках может иметь
> несколько иное значение, например - ироническое).Ну спасибо, Кэп. И все-таки я лично видел как интеловский Daniel Vetter например заботился о благополучии подсистемы. И формировании core технологий. В этом месте глаза не могут соврать - человек за крутую подсистему. Которая устроит всех. И оно вот так с большинством народа вокруг подсистемы. Мне это нравится - люди хотят делать свою работу круто, по высшему разряду. Это зрелище радует глаз.
> маркетология и не менее наглое вранье про вранье!
Ты бредишь. Мне просто нравится эта подсистема и как разработчики играют между собой. Это правда не значит что мне нравятся интеловские GPU. Черт возьми, driver team у интеля лучше чем сами GPU. Ну вот такой вот прикол, да. И ты знаешь, взбрыки интеграта от интеля и в маздае случаются. Там походу тоже костылять креатив HW team успевают не всегда и не везде.
Если интел хотел кого-то где-то подвинуть - им надо было разогнать нафиг разработчиков своего недоразумения. HW team. Но видимо не придумали где взять разработчиков и архитектуру лучше. Ну вот у амд лицензировали вроде сейчас.
> С самыми новыми - ну зафигарь "GPU hang intel" в любимый поисковик,
Слу, я и так знаю что hw team у интеля - рукож0пы. Но именно дровописаки в этом не виноваты, они на правах тех кто разгребает факапы. У них там драйвер состоит из quirk'ов и workaround'ов чуть более чем полностью. Железо такое, что ты от них хочешь? Парни делают конфетку из г-на. У того же амд - железо куда вменяемее и менее глючное. Хотя и у них иногда случается мистика в которой hw team разобраться не может. А сага с DC связана с тем что они очень хотят чтобы это им делали HW team, на этапе разработки железа. И таки там тоже своих шишек набили. Но в конце концов - процессы отлаживают, проблемы решают. Хорошо работает.
> пространных и хвалебных од интелю?
Я считаю что словил gpu hang на интеграте интеля даже в маздае, через полчаса после завершения установки системы. С встроенным в ос драйвером, обвешаном WHQL. Так что склонен видеть пойнт в мнении что у интеля хреновое железо GPU. И то что вкостылить его занимает 2.5 года - по большому счету это не тем людям претензии. Там hw team судя по всему оттрахать надо, а вовсе не. Надеюсь после лицензирования радеонов именно это с ними и произойдет, под угрозой сворачивания направления и выставления на мороз.
> в иксах отключает аппаратное ускорение полностью. Вот этим (как и отключением
> RC6) "лечили" (и лечат) GPU-hung.А это вообще чудесное сочетание, древний и шаткий код иксов который всем трогать страшно + глючное железо GPU. Это такое выигрышное комбо и заявка на победу что там даже сам дьявол потом не разберется - почему зависло это глюкало. Ну вот устроен этот мир так. АМДшники сделав GCN трезво оценили что даже пытаться не будут и заявили что glamor их все. А именно ускорение 2D в чистом виде - вообще кодить не стали. Наверное на интел посмотрели и с R600 выкусили более чем достаточно "счастья".
> Что оно медленное и жрет ЦПУ, можно наверное не упоминать. И о том, что о 3D в
> такой системе можно будет забыть, тоже.На самом деле 3D уже не привязано к иксам само по себе. А то что про это в курсе лишь некоторые программы, по историческим причинам - другой вопрос. На самом деле давно назрел сабж и расчистка костылей.
> Называя вещи своими именами, с точки зрения пользователя, никакая чорная дыра в
> юзерспейсе не должна приводить к подвешививанию графики в ядре.Расскажи это глюкавому железу. Ну а юзеру кто доктор, если он исправно покупает глюкало цатый раз к ряду и даже не трахает саппорт вендора? Как показал пример с спектром и мелтдауном - у интеля и CPU не сильно лучше делают. Но маскировали факапы поприличнее.
Если так сравнить ради интереса число разновидностей багов которые пробрали амд и интель - сразу как на ладони уровень QA в компаниях. И кто срезав угол побыстрее бабло рубать, а кто таки хотя-бы пытался проверить свое железо до этого.
> все рендерить через ЦПУ медленно, жрет батарейку и совсем не справляется
> с нагрузкой.Я знаю. Ну не повезло тебе с GPU. И чего?
> Если судить по хвалебным одам и агрессивной защите, я бы с этим не согласился.
Мне нравится как работает команда и направление развития подсистемы. А редкостная глюкавость и проблемность многих интеловских интеграшек - все-таки несколько иной аспект.
> начинать восхвалять свой выбор, как экзотический вид шоколада?
Я как-то в целом не особо рассматриваю интеграт как серьезный GPU, сорь. Да и интелу на самом деле интереснее всего GL ES, догадайся почему :). Он относительно простой и не требовательный. И врядли сильно пересекается с ускорением блин иксов - нет в андроиде этого жуткого угробища, потому что никого не устроит такой "user experience" :)
> На твое несчастье я таки читаю логи коммитов в майнлайн и помню ключевых персон из интеля. И поэтому ответственно заявляю: наглое вранье.Кстати, вспомнил. Не ты ли, на свое несчастье, многократно и гордо упоминал, что пользуешься АМДой, без всяких "секурити"?
Тебе говорят о реальных проблемах реального штеуда, а ты начинаешь защищать абстрактный интерфейс к ядру и не менее абстрактный интель, "помогающий коллегам", обвиняя попутно во вранье.
Извини, но чем тогда ты, нахваливающий и защищающий интель из под амды, лучше тех самых (гипотетических), нахваливающих и защищающих БЗДу из под Форточки, "заклятых врагов опенсурса"? ))
Пока в открытых не сделают реклокинг, лесом открытые.
А что wayland на nvidia все еще не работает?
Печально что Intel G31 не может полноценно работать с Wayland. Вся обработка идет через llvmpipe если используется данная графика. :(
> Печально что Intel G31 не может полноценно работать с Wayland. Вся обработка
> идет через llvmpipe если используется данная графика. :(В связи с чем?
Наверное, в связи с отсутствием поддержки нужной версии OpenGL. Это ж древность древняя.
> Наверное, в связи с отсутствием поддержки нужной версии OpenGL. Это ж древность древняя....? По минимуму вэйланд даже на VESA запускается?!
Отлично!
Long Live Wayland!
X*rg must die!
А по мне, так пусть оба проекта развиваются. Наличие выбора лучше, чем его отсутствие. У "вяленого" и "иксов" уже чётко сложились особенности и ниши применения. Каждый чем-то лучше и чем-то хуже.И вообще, "Long Live Rock'n'Roll!", как завещали Rainbow)
> А по мне, так пусть оба проекта развиваются. Наличие выбора лучше, чем
> его отсутствие. У "вяленого" и "иксов" уже чётко сложились особенности и
> ниши применения. Каждый чем-то лучше и чем-то хуже.
> И вообще, "Long Live Rock'n'Roll!", как завещали Rainbow)Увы, иксы дырявые, но вот то что гадкий глючащий гном в диком отрыве от KDE, вот это плохо. Все-таки наличие поддержки Redhat решает многое.
> Увы, иксы дырявые, но вот то что гадкий глючащий гном в диком
> отрыве от KDE, вот это плохо. Все-таки наличие поддержки Redhat решает
> многое.Ну так, Qt же продолжает пилить QtWayland.
в Вилларибо веселятся, а в Вилабаджо ещё моют посуду
> Наличие выбора лучше, чем его отсутствие.Я вас умоляю. И так уже хватает "выбора" KDE vs Gnome, так ещё и здесь хотите?
> Я вас умоляю. И так уже хватает "выбора" KDE vs Gnome, так ещё и здесь хотите?Хотите как в "виндах"? Когда у пользователя есть превосходный выбор из одного варианта?
Эээ, вы не программист? Вот надо, например, написать гуёвую программу. На чём писать? На иксах или вяленом? На qt или gtk? Для kde или gnome? Запаковать в deb или rpm? Это не считая того, что сделав выбор, вторая половина будет полностью упущена - запаковал в deb и все rpm-based дистрибутивы в пролёте (грубо говоря).В виндах и маках есть единый API задаваемый партией - и ты не тратишь время на разбор "а что бы мне сегодня выбрать, чтобы сделать то-то"? Ты просто тупо берёшь и делаешь, потому что выбора-то всё равно нет, можно только так и не иначе - отсюда время разработчика и сосредоточено на определённом пути действия, а не на субъективных каких-то предпочтениях.
> На чём писать?Нет можешь выбрать - подкинь монетку
> Эээ, вы не программист? Вот надо, например, написать гуёвую программу. На чём
> писать? На иксах или вяленом? На qt или gtk? Для kde
> или gnome? Запаковать в deb или rpm? Это не считая того,
> что сделав выбор, вторая половина будет полностью упущена - запаковал в
> deb и все rpm-based дистрибутивы в пролёте (грубо говоря).Я программист. Для рендера пишется абстракция на уровне команд рендера или оконных примитивов. Потом это обёртывается в два варианта: Qt и GTK — всего лишь по параметру сборки меняется код транслятора вывода. Что до deb и rpm - два скрипта сборки из одного дерева исходников. Есть такое понятие, "кроссплатформенное программирование" и оно, вообще-то, считается признаком очень хорошего и адекватного тона, а не тот вариант, который Вы предлагаете: я пишу под что-то одно потому, что мне так удобнее. И в это понятие входит не только разность платформ ОС, но и фреймворков построения интерфейса.
Только людям обычно охота повоевать, какой фреймворк идеологически правильный, Qt или Gtk. А ничего, что они не единственные в своём роде??? И что под виндой ещё есть богомерзкий MFC, да обыкновенный WinAPI? Или расширять поддержку через абстракции уже не признак программиста?
> В виндах и маках есть единый API задаваемый партией - и ты
> не тратишь время на разбор "а что бы мне сегодня выбрать,
> чтобы сделать то-то"? Ты просто тупо берёшь и делаешь, потому что
> выбора-то всё равно нет, можно только так и не иначе -
> отсюда время разработчика и сосредоточено на определённом пути действия, а не
> на субъективных каких-то предпочтениях.А потом они придумывают MFC и .Net, и "единая политика партии" идёт к чертям под хвост) Я не пойму, Вы наивный человек или мало осведомлённый? Или может начинали знакомство с компьютером через покупку iPhone?
Не надо заниматься дублированием кода по каждому чиху, тогда и проблем особых не будет! Пора бы уже прекращать писать быстро и начинать писать адекватно!
> Для рендера пишется абстракция на уровне команд рендера или оконных примитивовЧто вы говорите? Ну good luck :)
> Потом это обёртывается в два варианта: Qt и GTK — всего лишь по параметру сборки меняется код транслятора вывода
Щито? Вы на джаваскрипте программируете? А ничего, что и Qt и GTK предоставляют свои API для работы с файлами, потоками, таймерами, окнами и т.д. и каждый своим способом? Какой вы там параметр сборки собрались менять, если у вас получатся абсолютно две разные программы со своими заголовочными файлами, функциями и скриптами сборки? Или вы для "калькулятора" создадите абстракцию, которая отдельно ложится на gtk или qt (выбирается опцией компиляции)? Вы понимаете, что эта абстракция по сути повторит весь функционал qt и gtk? Ради чего такое делать?
В кроссплатформенных гуёвых проектах есть абстракции от платформы - windows или mac os. Но когда туда добавляется ещё и абстракции самой абстракции типа gtk и qt - это уже двойная бесполезная работа, не находите? Не было бы круто, если бы была бы платформа Xorg какая-нибудь и всё на этом?
> Что до deb и rpm - два скрипта сборки из одного дерева исходников
Да-да, а ещё скрипты для CentOS 6, 7 и Fedora, а ещё Debian 8, 9 и Ubuntu - good luck.
> Есть такое понятие, "кроссплатформенное программирование" и оно, вообще-то, считается признаком очень хорошего и адекватного тона, а не тот вариант, который Вы предлагаете: я пишу под что-то одно потому, что мне так удобнее. И в это понятие входит не только разность платформ ОС, но и фреймворков построения интерфейса.
Это прекрасно, что вы слышали такие понятия. Пишите на java и будет вам кроссплатформенно всё из коробки - это ж хороший тон, зачем вам qt и gtk тогда? Или вот вам задачка - напишите кроссплатформенную игру и опубликуйте её в маркете винды и эпла. Что? Как-то тормознуто получается, да? Абстракции съедают производительность, да? Дублируется логика, да? Ай-яй-яй. Какой "нехороший и неадекватный тон"! Выходит приходится писать что-то пер-platform и не потому что "мне так удобнее", а потому что это две разные платформы.
> Только людям обычно охота повоевать, какой фреймворк идеологически правильный, Qt или Gtk
К сожалению, да. Поэтому нафиг выбор в виде двух яиц, разбейте одно, пусть живёт другое и не будет никаких воин.
> И что под виндой ещё есть богомерзкий MFC, да обыкновенный WinAPI?
> А потом они придумывают MFC и .Net, и "единая политика партии" идёт к чертям под хвост)Сейчас, если в винде надо написать гуёвую программу и выложить в маркет - берите xaml, не надо в маркет - winforms (c++ или c# - что больше знаете). В макоси вообще cocoa и всё тут - это что плохо что ли?
Если взять Qt или GTK - то да, гуй работать будет везде. Но тогда скажите разработчикам из LibreOffice, что они дураки, что пишут собственный кроссплатформенный гуи тулкит (https://docs.libreoffice.org/vcl.html).
> Или может начинали знакомство с компьютером через покупку iPhone?
О, да вы, как вижу, "эксперт в споре со школьниками". Я, видимо, сказал какой-то триггер-слово, что под конец вас понесло.
> Не надо заниматься дублированием кода по каждому чиху, тогда и проблем особых не будет!
Вы несёте околесицу.
> Пора бы уже прекращать писать быстро и начинать писать адекватно!
Аминь.
> Щито? Вы на джаваскрипте программируете? А ничего, что и Qt и GTK
> предоставляют свои API для работы с файлами, потоками, таймерами, окнами и
> т.д. и каждый своим способом? Какой вы там параметр сборки собрались
> менять, если у вас получатся абсолютно две разные программы со своими
> заголовочными файлами, функциями и скриптами сборки? Или вы для "калькулятора" создадите
> абстракцию, которая отдельно ложится на gtk или qt (выбирается опцией компиляции)?
> Вы понимаете, что эта абстракция по сути повторит весь функционал qt
> и gtk? Ради чего такое делать?Уже имею опыт написания под Qt, GTK и WinAPI, правда разовый. В основном работаю с Qt.
Для ПО создаются архитектурные элементы: 1) Инициатор; 2) Транслятор GUI; 3) Исполнитель; 4) Хранитель; 5) Обработчик протокола. Софтина являлась клиентом для удалённого сервиса.Класс "транслятора GUI" цеплял всё, что надо и исполнял логику реакции интерфейса на события. Именно конечной реакции, а не отлова. От него наследовался класс, реализующий собственно диалог. Вот он-то и есть фреймворкозависимый. Всё, с чем он работает, — с фреймворком GUI. Больше ни с чем.
Параметр сборки — правило для Makefile (ненавижу юродивый CMake!). Собственно, для винды это — профиль под VC. В зависимости от платформы и фреймворка собиралась морда та, которая нужно. Задача была выполнена. не скулил и не плакался крокодильими слезами, "ах как плохо, что куча вариантов интерфейса!".
> В кроссплатформенных гуёвых проектах есть абстракции от платформы - windows или mac
> os. Но когда туда добавляется ещё и абстракции самой абстракции типа
> gtk и qt - это уже двойная бесполезная работа, не находите?
> Не было бы круто, если бы была бы платформа Xorg какая-нибудь
> и всё на этом?Всего лишь отделяется фреймворконезависимая логика приложения от зависимой. Вот и всё. Просто не надо писать исполнительную логику посреди кода GUI! А с остальной частью можно поступать так же.
> Да-да, а ещё скрипты для CentOS 6, 7 и Fedora, а ещё
> Debian 8, 9 и Ubuntu - good luck.Да. Лежит отдельно Shell-файлик, который определяет ОС, выдаёт по запросам нужные параметры для скриптов сборки. Собственно скрипты сборки универсальны и привязаны лишь к типу пакета (deb, rpm).
> Это прекрасно, что вы слышали такие понятия. Пишите на java и будет
> вам кроссплатформенно всё из коробки - это ж хороший тон, зачем
> вам qt и gtk тогда? Или вот вам задачка - напишите
> кроссплатформенную игру и опубликуйте её в маркете винды и эпла. Что?
> Как-то тормознуто получается, да? Абстракции съедают производительность, да? Дублируется
> логика, да? Ай-яй-яй. Какой "нехороший и неадекватный тон"! Выходит приходится писать
> что-то пер-platform и не потому что "мне так удобнее", а потому
> что это две разные платформы.Повторяю: опыт есть, но для desktop-приложений, а не для мобильных. Но даже в этом случае есть решение. По сему ёрничанье тут не уместно. Если Вы не умеете в абстракцию без тормозов, то что тут говорить? Наверное лишь упомянуть, что она прорабатываться может не только на уровне исполнения кода.
> К сожалению, да. Поэтому нафиг выбор в виде двух яиц, разбейте одно,
> пусть живёт другое и не будет никаких воин.Тут я бы предпочёл окончательное деление. Скажем, пусть будет какая-нибудь KDE OS и Gnome OS, от которых бы отталкивались остальные дистрибутивы. Чуть ближе к стандартизации.
> Сейчас, если в винде надо написать гуёвую программу и выложить в маркет
> - берите xaml, не надо в маркет - winforms (c++ или
> c# - что больше знаете). В макоси вообще cocoa и всё
> тут - это что плохо что ли?Логика одна. Интерфейсы разные. Удивляет, когда люди столь категорично делят программы на "мобильные", "дэсктопные" и "серверные". Логика расчётов и исполнительная могут быть одинаковыми для всех, а оболочка — отдельная ипостась, будь она хоть мобильной, хоть настольной, хоть вообще WEB-мордой. Любят же люди нещадно дублировать код! По сто раз писать одно и то же.
> Если взять Qt или GTK - то да, гуй работать будет везде.
> Но тогда скажите разработчикам из LibreOffice, что они дураки, что пишут
> собственный кроссплатформенный гуи тулкит (https://docs.libreoffice.org/vcl.html).Будет третий GUI Framework. Выбор — хорошее дело.
И ещё раз повторю: Быстро написанный код либо тормозной, либо монструозный по архитектурному решению, либо и вовсе франкенштейн, при работе с которым охота отправить его создателя на гильотину. Чем проще, тем надёжнее. Это правило не отменяет здоровой абстракции в меру и по порядку без перегибов.
xWidget изобрел?
Чота создается у меня впечатление, что вы не совсем в курсе того, о чем пишете...
Вот и мысли, вроде, правильные, но на выходе каша такая, что прям ахтунг...>> Для рендера пишется абстракция на уровне команд рендера или оконных примитивов.
В смысле, ее пишете вы? Вы пишете логику работы с графическими примитивами?
>> Потом это обёртывается в два варианта: Qt и GTK
А потом рассказываете Qt и Gtk, что не надо использовать EGL/OpenGL, а надо использовать "вашу логику"?
>>всего лишь по параметру сборки меняется код транслятора вывода.
Ага, и интерфейс на Qt или Gtk вы тоже не пишете? Пишете на чем-то универсальном, а потом транслируете это все в исходники Qt или Gtk ключом мифического "транслятора вывода"? Т.е. у вас там сгенеренный код?
Скажите, вы реально считаете, что переписать QtCore + Qt/QML и Gtk для поддержки кастомного рендера, потом сгенерить какие-то файлы описания интерфейсов из чего-то "универсального" по ключу - это нормальный подход??? Вы реально утверждаете, что ОНО у вас работает???
Что Qt, что Gtk - это ФРЕЙМВОРКИ. Погуглите, заодно про "инверсию зависимостей" почитайте. Это НЕ библиотеки, тем более не библиотеки с одинаковым API/ABI, чтобы их можно было при сборке переключать ключом компилятора...
А потом жалуются, что Qt тормозит
А после того как WinAPI "устарел" - "устарели" и WinForms. И появился WPF. А для себя MS вообще по жизни использует custom controls. Что они, плебс всякий чтоли, чтобы их программы выглядели как домашка студня и прочий крап от ISV? Поэтому реально в виндах живет штук 5-6 разных систем контролов на все вкусы.
>>Вот надо, например, написать гуёвую программу. На чём писать? На иксах или вяленом? На qt или gtk? Для kde или gnome?Для всего есть wxWidgets - и не только на плюсах. Он нативно рисуется под вендой, под ГТК и есть недоделанный порт под QT. Т.е. зависимость твоей проги от ДЕ снимается. На нем, кстати, написан UnrealEd, Code::Blocks и много других крупных проектов.
>>>Вот надо, например, написать гуёвую программу. На чём писать? На иксах или вяленом? На qt или gtk? Для kde или gnome?
> Для всего есть wxWidgets - и не только на плюсах. Он нативно
> рисуется под вендой, под ГТК и есть недоделанный порт под QT.
> Т.е. зависимость твоей проги от ДЕ снимается. На нем, кстати, написан
> UnrealEd, Code::Blocks и много других крупных проектов.Бугага. Начнете программировать ЭТО - расскажете, как оно)))
>> Эээ, вы не программист?Вы, вероятно, тоже?
>> Вот надо, например, написать гуёвую программу.
Окей, надо - пишите, в чем проблема?
>> На чём писать?
Очевидно, от более подробного описания задачи зависит.
>> На иксах или вяленом?
Ну, во первых, не "НА", а "ПОД". Что иксы, что wayland - это не язык программирования, и даже не фреймворк. Это протокол, который вы поддерживаете/не поддерживаете.
>> На qt или gtk?
Собственно, от задачи/предпочтений. Если уж вы уперлись в выбор Qt/Gtk, значит программа не слишком специфическая - более-менее стандартный интерфейс + набор какой-то бизнес-логики. Тогда, ВНИМАНИЕ, вопрос, каким боком вас волнует выбор X11 vs Wayland? Вот что фреймворк поддерживает, под тем и работать будет, не больше и не меньше. Вы - пишете программу, графический сервер вас не касается.
>> Для kde или gnome?
А чем они, собственно, с точки зрения программы различаются? Собственно, программе тупо срать с большой колокольни, под чем ее запустили. Нет, если вы пишете что-то гномоспецифичное, изначально предназначенное для работы в гномоокружении, оно, вероятно, под кедами, например, попросит туеву хучу зависимостей с собой принести, но тут уж в постановке задачи вопрос.
Если задача стоит "создать нативное приложение для гномо-окружения со своей особой спецификой" или "создать плагин к Gnome" - пишите лучше на Gtk и со своей особой гномо-спецификой. Если вы пишете "просто приложение", то какая вам разница? Что Gtk-приложения в KDE работают, что Qt-приложения в Gtk. Причем вообще безо всяких проблем, я проверял.>> Запаковать в deb или rpm?
В момент разработки - какая разница вообще? Доставка приложения пользователю - совершенно особая задача. Исходники-то у вас не пропадут, tarball никуда не денется. Упаковали как придумали, понадобилось что-то еще - упаковали еще раз, в чем проблема-то? Лень упаковывать много раз - snap/flatpack вам в помощь - они песочница, оно везде заведется.
>> Это не считая того, что сделав выбор, вторая половина будет полностью упущена - запаковал в deb и все rpm-based дистрибутивы в пролёте (грубо говоря).
В смысле, ты в deb запаковал, и все? Пропала программа? Пока из deb'а не достанешь, в rpm упаковать никак?
>> В виндах и маках есть единый API задаваемый партией - и ты не тратишь время на разбор "а что бы мне сегодня выбрать, чтобы сделать то-то"? Ты просто тупо берёшь и делаешь, потому что выбора-то всё равно нет, можно только так и не иначе -
Хм, аж поперхнулся. Т.е. в винде для реализации GUI-приложения выбора нет? Нет вот этого всего winforms vs MFC vs UWP? При этом оно - три реально используемых платформы ВНУТРИ одной ОС, они непереносимы на другие, т.е. на Linux и прочих работать не будут. Это не вспоминая про кроссплатформенные фреймворки, включая те же Qt, Gtk, WxWidgets, которые вполне себе используются, кучи фреймворков-одного-приложения и всяческой хрени класса "а давайте я оберну пол-браузера в экзешник и буду показывать интерфейс там, сайт-то уже есть, зачем писать второй раз" типа электронов и прочего-прочего, Xamarin тот же...
Вы просто не в теме, честно.>> отсюда время разработчика и сосредоточено на определённом пути действия, а не на субъективных каких-то предпочтениях.
Глупости же... При этом субъективные предпочтения вполне себе объективный вес имеют. Если надо написать приложение, при этом на Gtk оно получится "чуть-чуть правильней", а имеющийся разработчик знает только Qt, не надо заставлять его переучиваться. Один хрен куйня получится.
> Окей, надо - пишите, в чем проблема?Вот скажите, в чём смысловая нагрузка этого вашего предложения?
> Это протокол, который вы поддерживаете/не поддерживаете.
Да, в этом и проблема выбора. Что поддерживать? Иксы или вяленого? Зачем выбирать иксы, если их всё хоронят и вот-вот выстрелит вяленый? А зачем выбирать вяленого, если до сих пор он не стабилизировался, что слишком часто ломается совместимость?
> Собственно, от задачи/предпочтений. Если уж вы уперлись в выбор Qt/Gtk
Вот-вот, именно я про это и говорю. Вместо того, чтобы тратить время на разработку приложения, ты должен думать и разбираться "а чей ты больше фанат".
> Тогда, ВНИМАНИЕ, вопрос, каким боком вас волнует выбор X11 vs Wayland? ... Вы - пишете программу, графический сервер вас не касается.
Неудивительно, что ваш комментарий наполнен желчью. Вы пытаетесь найти конкретный узкий случай, но его нет - я говорю в общем и привожу разные примеры.
> А чем они, собственно, с точки зрения программы различаются?
Вы серьёзно? С точки зрения программы чем отличаются два совершенно разных API? Один на С++, а другой на Си? Чем различаются?
> Собственно, программе тупо срать с большой колокольни, под чем ее запустили.
Речь не про запуск, а про страдания разработки.
> Если задача стоит "создать нативное приложение для гномо-окружения со своей особой спецификой" или "создать плагин к Gnome" - пишите лучше на Gtk и со своей особой гномо-спецификой. Если вы пишете "просто приложение", то какая вам разница? Что Gtk-приложения в KDE работают, что Qt-приложения в Gtk. Причем вообще безо всяких проблем, я проверял.
Вот вы разве тут уже не видите проблемы? "Создать нативное приложение для гномо-окружения" - почему задача стоит так узко? Если сказано - написать прогу под винду - коротко и лаконично. Или написать прогу под макось. А тут: "написать прогу для гнома" или "написать прогу для кде". Причём суть одна - прога будет гуёвая, запущена на каком-нибудь линуксе. К чему этот выбор - гном или кде, если на выходе всё равно будет одно и то же?
> Упаковали как придумали, понадобилось что-то еще - упаковали еще раз, в чем проблема-то? Лень упаковывать много раз - snap/flatpack вам в помощь - они песочница, оно везде заведется.
Вот-вот, о том и речь - хочешь используй то, хочешь это, вместо того, чтобы была одна чёткая инструкция как запаковать свою программу, чтобы её раздавать пользователям.
> В смысле, ты в deb запаковал, и все? Пропала программа? Пока из deb'а не достанешь, в rpm упаковать никак?
Чтобы предусмотреть возможность запаковки под всевозможные пакетные менеджеры, нужно затратить определённое количество времени и сил, вместо того, что сосредоточить своё время и силы на самой непосредственной разработке.
> Т.е. в винде для реализации GUI-приложения выбора нет? Нет вот этого всего winforms vs MFC vs UWP?
Вы сравниваете несравнимые вещи. Есть линия партии, от которой вы не можете отойти. Если надо написать приложение для виндового маркета у вас что, так много выбора? Если надо написать приложение под мак - у вас что, много выбора?
> Вы просто не в теме, честно.
Поди потому что
> я проверял.
?
> При этом субъективные предпочтения вполне себе объективный вес имеют. Если надо написать приложение, при этом на Gtk оно получится "чуть-чуть правильней", а имеющийся разработчик знает только Qt, не надо заставлять его переучиваться. Один хрен куйня получится.
По вашей логике - это два разных человека, которые знают два разных API, а на выходе которые дают один и тот же результат - гуй приложение, которое запустится на каком-нибудь линуксе.
Все бы ничего, но многие, пусть и костыльные, но тем не менее удобные и нужные решения не булки работать с Wayland by design, что пеяалит, так как это в том числе отоичало по удобству никсы от макоси или вантуза
Ме тоже зело печалят булки на вайланде. Чувствую твою боль, бро.
Он хотел сказать, что Wayland сейчас промеж булок
Пока Wayland пеяалит булки Xorg стабильно работает
Так я не понял, Вейленд уже победил или нет? Вот смотрю всякие фералы делают порты Linux-игр на Vulkan. Ну а толку то от этого вулкана на древнем как гoвно мамонта дисплейном сервере, который для игр то не предназначен, глюкодром?
Эм.. если я не ошибаюсь (а могу), то для игр нет разницы в производительности под X или wayland
Есть разница в отзывчивости: wayland не предоставляет приложениям возможности прямого вывода на экран by design, а буферизация увеличивает input lag.
Впрочем, в иксах с композитным менеджером лаг ещё больше, для минимизации лага нужно использовать иксы с классическим выводом.
ЕМНИП, если композитный менеджер это поддерживает, в полноэкранном режиме вывод на экран может идти напрямую. Правда вероятность словить проблем при Alt-Tab увеличивается на 99%.Вообще всё это чепуха. Буферизация и архитектура вывода на экран имеют значение только если производительность упирается в fill-rate (с которым сейчас справляются даже мобилки, работающие на разрешениях значительно больше 1024x768). И когда для них это было важно (не в курсе, актуально ли это до сих пор), в мобилках поставлялся *аппаратный* композитор.
> Буферизация и архитектура вывода на экран имеют значение только если производительность упирается в fill-rateНеверно. Буферизация в любом случае увеличивает задержку вывода на экран, вне зависимости от того, остаётся запас производительности отрисовки или нет. Как и любые средства борьбы с tearing'ом — это палка о двух концах: с одной стороны низкая задержка отображения ввода на экране, с другой — целостность картинки. На соревновательном уровне все вменяемые игроки предпочитают первое, отключая vsync'и всех разновидностей и выкручивая fps на максимально доступный и превышающий частоту вертикальной развёртки монитора.
> Есть разница в отзывчивости: wayland не предоставляет приложениям возможности прямого
> вывода на экран by design,Это какой design? Рисунок в статье если что не полностью отражает картину. Там на самом деле через wayland согласуется только data path, а данные идут из аппы в libdrm и это довольно быстрый и прямой путь.
Более того - в иксах до того как данные пойдут на экран сперва надо их выколупать из протокола иксов со всем его оверхедом. И это никак не идет на пользу латенси. Конечно же есть расширения. Типа xv какого-нибудь и прочих xshm. Но они как бы опциональны и предполагается что у вас должен быть план на случай если их нет. Поэтому быстрый вывод графики через иксы вообще являет собой смесь геморроя, костылей и грабель. И почему это должно быть настолько сложно, криво, хрупко и глючно - загадка природы.
Фералы не умеют готовить вулкан, почему-то те же самые игры, но запущенные через Wine с DXVK, работают - лучше, чем нативные порты, а про изначально вулкан-игры вообще молчу, недавний Wolfenstein 2, что на оффтопике, что через Wine показывает +-одинаковую производительность
> Так я не понял, Вейленд уже победил или нет? Вот смотрю всякие
> фералы делают порты Linux-игр на Vulkan. Ну а толку то от
> этого вулкана на древнем как гoвно мамонта дисплейном сервере, который для
> игр то не предназначен, глюкодром?Неправильно задан вопрос. "Толку-то от этого Ферала, если там - транслятор из Direct3D?"
> Ну а толку то от этого вулкана на древнем как гoвно мамонта дисплейном сервереИ какая же часть дисплейного сервера мешает месье играть в игры?
Та, которая находится между стулом и монитором.
> этого вулкана на древнем как гoвно мамонта дисплейном сервере,В фулскрине GL и Vulkan рисуют напрямую через DRM/KMS, вообще без участия иксов. Если это оконный режим... ну вот тут ой, чтобы объединить картинку из игры и остальные части десктопа - композитинг сделать все-таки придется.
И вот в оконном режиме производительнсть игр в иксах ясенхрен "не очень".
"Не очень" отличается? Очень может быть.
картинки показывают стройность и превосходство вялого. Выкусите, атеисты.
> картинки показывают стройность и превосходство вялого. Выкусите, атеисты.Только одно пожелание: Возможность удалённой отрисовки, как у X-ов. Причём желательно кроссплатформенно. А так — пусть развивается.
Сдается мне что это не к вейланду вопрос. Вейланд композитор. Рисует qt и gtk. Удалённую отрисовку если сделают gtk qt то будет. Но если до сих пор не задумались об этом - то усё..И даже под иксами qt и gtk гоняют же битмапы. Не ?
Вейланд это протокол, как X11. Композитор это KWin, Mutter и т.д. - фактически, они вбирают в себя часть функций Xorg.
> Вейланд это протокол, как X11.Не так. В X11 данные in-band идут. А тут через протокол согласование только. Основной поток данных - напрямую заворачивают в подсистему DRM. Так что не надо парсить на скорость гигазы данных лишний раз. В иксах какое-то подобие чего-то такого ну не то что совсем невозможно, но через жуткую задницу и работает через пень-колоду. Так что даже в 2018 году вопрос с тирингом блин не закрыт.
Я не сравнивал между собой X11 и Wayland, я отвечал на "Wayland это композитор".
> И даже под иксами qt и gtk гоняют же битмапы. Не ?Не проверял... Но даже если так, возможность удалённо стартануть оконце во многих случаях более вкусная функция, чем транслировать весь "рабочий стол".
просто, если все равно и так и так битмапы гонять, то не проще ли просто запросить сессию с ныжным размером экрана и запустить удаленноё приложение на весь экран?
> просто, если все равно и так и так битмапы гонять, то не
> проще ли просто запросить сессию с ныжным размером экрана и запустить
> удаленноё приложение на весь экран?Тут закралась логическая ошибка: Сессия — одна, а удалённых графических контекстов может быть много. Собственно, они-то и отображают окна.
Я не против такого подхода. Просто часто удобнее, когда под руками просто консоль, а рисуется только окно вызванного приложения, но не весь рабочий стол. В случае с X-ами это уже давно успешно применяется, а в случае с "Вэйландом" ещё толком не стало стабильным и реализовано через костыли в оконном менеджере.
> И даже под иксами qt и gtk гоняют же битмапы. Не ?хуже - они mouse position с рейтом в сотни запросов в секунду при некоторых условиях гоняют.
Поройтесь в древних тикетах VBox'а - там найдете прекрасную тему о том, как программа, нормально работавшая (ну с очевидными поправками на ширину полосы) в удаленной сессии, после очередного апгрейда qt работать перестала совсем, после долгих попыток что-то улучшить (явно без понимания, потому что странно требовать от разработчиков виртуализатора разбираться в потрохах рисовалок) стала работать кое-как (причем упираясь не в полосу, а в rtt - в соседнюю комнату все прекрасно, а вот попробуйте-ка что-нибудь с rtt >50 (в Калининград, к примеру, бывает и 90, и это еще не худший канал). Для чистоты эксперимента - по гигабитному линку ;-)Потом поставьте (если найдете работающий сетап) какой-нибудь vbox версии 3.2 - изумитесь. Что, оказывается, и гигабиты не нужны, и с большим rtt подтормаживает, но жить вполне можно...
> хуже - они mouse position с рейтом в сотни запросов в секунду
> при некоторых условиях гоняют.Для начала - услуги иксов по битмапам и проч оказались неактуальны, неюзабельны и невостребованы и программы пришли к рендеру себя целиком силами тулкитов. Потому что тулкиты это делают симпатично, дружелюбно и лицом к програмерам, да еще соответствуют современным реалиям и вообще, абстрагируют всю эту гадость. Так что прога и на винде запустится, пожалуй. И в макоси. А програмер даже не узнает что там win32 какой-то оказывается у них, или какое там еще какао.
А иксам осталась роль плевалки битмапа. Кривой, хреновой, тормозной и переусложненной плевалки. Плевалка битмапов может быть в 20 раз проще и не требовать такой камасутры с майнтенансом. Собственно это и есть повод чтобы прибить их в пользу вэйланда.
Ну а иксы - это хреновая графика по сети и хреновая локальная плевалка битмапов. А еще они спейсшаттл, когда заходит вопрос о майнтенансе и затратах на него.
Давно работает.
> Давно работает.Через костыли в оконном менеджере.
Нам нужен Universal Cross-platform Graphics Protocol - UCGP.
зависящий от systemd-ucgp, kernel-ucgp-video-settings.ko, и, желательно, оформленный в виде docker-контейнера.
> зависящий от systemd-ucgp, kernel-ucgp-video-settings.ko, и, желательно, оформленный
> в виде docker-контейнера.Ты в своем праве как обычно вопить этанинужна!!!111. А потом линуксоиды будут смотреть какое-нибудь там видео в 4K, в стерео, с freesync и прочим - без тиринга. А ты будешь шипеть "драйверов нет" и дуалбутаться в маздай.
Ну так и поделом тебе за дуалбут в маздай. Какой смысл с такими персонажами считаться? Пусть у майкрософта тогда и требуют учет своих интересов.
>> зависящий от systemd-ucgp, kernel-ucgp-video-settings.ko, и, желательно, оформленный
>> в виде docker-контейнера.
> Ты в своем праве как обычно вопить этанинужна!!!111. А потом линуксоиды будут
> смотреть какое-нибудь там видео в 4K, в стерео, с freesync иНеплохо у тебя бомбануло. Больная тема, да?
Но ты все равно глянь еще раз на расшифровку UCGP и перечитай свой пламенный привет.
> Для FreeBSD подготовлены порты, необходимые для сборки KDE с поддержкой WaylandПомимо этого, обновился ключевой для графической подсистемы BSD порт graphics/mesa-dri - сегодня вышли версии 17.3.8 и несколько минут спустя - 18.0.0: https://www.freshports.org/graphics/mesa-dri/
> Развивается десктоп-окружение Orbital, работающее только на базе технологий Wayland;Да вы издеваетесь что ли?
Cairo-Dock с weston'ом тоже уже давно не работает. Плагин выпилили.
В тред призывается один известный модератор с вопросом, как там поддержка Wayland в базальте.
> как там поддержка Wayland в базальте......на Эльбрусе, добавил бы я к вопросу :)
И это тоже!
А с донатом сайту и модерацией решили вопрос?
Наш паровоз по-прежнему вперёд, назад, вперёд, назад, назад и пофиг остановка?
Вы этот вопрос МЦСТ задайте, они пилят полноценный порт Debian на Эльбрус и поставляют его.
И то, что порт не на последнем выпуске deb, то и "непутёвая земля" там не свежая.
> Вы этот вопрос МЦСТ задайте, они пилят полноценный порт Debian на Эльбрус и поставляют его.Чтобы пилить что-то полноценное, надо уметь, а они не умеют. И ума ограничиться простой пересборкой пакетов им не хватает.
> Вы этот вопрос МЦСТ задайте, они пилят полноценный порт Debian на Эльбрус
> и поставляют его.Не вижу информации об этом на сайте Debian. Возможно, слухи о полноценности порта были сильно преувеличены?
С учётом того, что DE там XFCE (на Эльбрусе), KDE и Mate, то рановато. Вот когда чуть менее, чем полностью отпадёт нужда популярных приложений в X-Wayland, то смысл есть, всё остальное - PR и пoнты.
> Документировано применение двойной буферизации в wl_subcompositor.get_subsurfaceБраво, а давайте теперь в вэйланде применять и тройную буферизацию. Говорили ведь, что не нужно будет двойной буферизации, а теперь оказывается даже можно. В навоз превращается этот вэйланд. Вот нельзя до ума довести начатое, обязательно нужен костыль, нужно больше костылей. В задницу этот линукс, господа. Простите, лучше на винде поиграю.
>> Документировано применение двойной буферизации в wl_subcompositor.get_subsurface
> Браво, а давайте теперь в вэйланде применять и тройную буферизацию. Говорили ведь,
> что не нужно будет двойной буферизации, а теперь оказывается даже можно.
> В навоз превращается этот вэйланд. Вот нельзя до ума довести начатое,
> обязательно нужен костыль, нужно больше костылей. В задницу этот линукс, господа.
> Простите, лучше на винде поиграю.Это для сабкомпозитора, а не для самого Wayland.
Вот так все уже сваливают. А кто тогда останется? Я, Шигорин, Прокудин и Чирков?
ЗЫ: Про себя я пошутил :))
>> Документировано применение двойной буферизации в wl_subcompositor.get_subsurface
> Браво, а давайте теперь в вэйланде применять и тройную буферизацию. Говорили ведь,
> что не нужно будет двойной буферизации, а теперь оказывается даже можно.
> В навоз превращается этот вэйланд. Вот нельзя до ума довести начатое,
> обязательно нужен костыль, нужно больше костылей. В задницу этот линукс, господа.
> Простите, лучше на винде поиграю.Игроки всегда чем-то недовольны.
Разве игры это не двигатель прогресса?
вроде как, порево
Объективно развитию рынка домашних ПК служили игры.
Если бы людям нужно было только текстовый процессор и смотреть видео в интернете, то все бы до сих пор на 386 сидели.
> Говорили ведь, что не нужно будет двойной буферизации, а теперь оказывается даже можно.Речь о разных буферезациях.
В новости речь о том, документировано запрашивание нескольких буферов у композитора с целью готовить кадры в них параллельно. Это хорошо и повышает fps в некоторых случаях.
Раньше говорили про то, что в иксах, при наличии композитного менеджера, кадр от приложения буферизуется (по-сути копируется) 2-3 раза просто так. Без какой-либо на то необходимости.
И то и другое называют двойной буферизацией, хотя вещи кардинально разные.
дайте мне для вяленого аналог X over SSH
И что тебе мешает?
Если твой Desktop на вяленом, а сервак на X.org, то я думаю у тебя не должно возникнуть никаких проблем
> Desktop на вяленом, а сервак на X.orgВидите ли, на десктопе, как раз таки, запускается СЕРВАК X.org, а на серваке - клиент X.org. Если на десктопе у Вас "вяленый" (т.е. СЕРВАКА X.org нет как класса от слова совсем), то клиенту подключаться некуда хоть через ssh, хоть напрямую к порту...
>> Desktop на вяленом, а сервак на X.org
> Видите ли, на десктопе, как раз таки, запускается СЕРВАК X.org, а на
> серваке - клиент X.org. Если на десктопе у Вас "вяленый"
> (т.е. СЕРВАКА X.org нет как класса от слова совсем), то клиенту
> подключаться некуда хоть через ssh, хоть напрямую к порту...Кто тебе сказал такую чушь? Почему тебя не устраивает X over ssh, зачем тебе нужен какой-то новый протокол?
> Кто тебе сказал такую чушь?Вообще-то он как раз правильно всё написал
> Почему тебя не устраивает X over ssh, зачем тебе нужен какой-то новый протокол?
Попробуй прочитать написанное внимательно. Там дан четкий ответ.
Если речь про Qt - то тот умеет просто раздавать картинку сразу в браузер.
https://blog.qt.io/blog/2017/07/07/qt-webgl-streaming-merged/
Еще есть средней глючности бэкенд, который рендерит аппликуху в VNC.
GTK тоже: https://developer.gnome.org/gtk3/stable/gtk-broadway.html
> Если речь про Qt - то тот умеет просто раздавать картинку сразу
> в браузер.
> https://blog.qt.io/blog/2017/07/07/qt-webgl-streaming-merged/
> Еще есть средней глючности бэкенд, который рендерит аппликуху в VNC.
> раздавать картинку сразу в браузера можно без такой хе*ты ?
> средней глючности бэкенд ... в VNC
и без такой можно ?
хотя иксы через ссш не сильно лучше видеотрансляции.... но хотяб не вызывают создание всего "маленького десктопа"
Вангую, что вскоре сделают опцию для проброса какого-нибудь VNC через SSH с автоматическим запуском сервера и клиента на время сеанса, так что с точки зрения пользователя все будет работать так же. Проброс X все равно уже не работает эффективно с современными тулкитами и приложениями.
> Проброс X все равно уже не работает эффективно с современными тулкитами и приложениями.почему так?
Потому что они уже не обходятся командами протокола для рисования на стороне сервера и гоняют по сети растровые буферы отрисованные на клиенте.
> Потому что они уже не обходятся командами протокола для рисования на стороне
> сервера и гоняют по сети растровые буферы отрисованные на клиенте.а почему они не обходятся?
если более сложные игры гоняя картинку в видяшку умудряются обходится всего лишь командами опенгл, а не гонять только битмапыи можете прокомментировать это? https://www.opennet.ru/openforum/vsluhforumID3/114049.html#120
> а почему они не обходятся?
> если более сложные игры гоняя картинку в видяшку умудряются обходится всего лишь
> командами опенгл, а не гонять только битмапыНе хотят. Дело, может быть, не в том, что архитектура иксов непригодна для своих задач, а в том, что разработчики тулкитов и приложений не нее забили. И что теперь делать? Вы все равно не заставите всех разработчиков библиотек и приложений (тем более кроссплатформенных) думать о сетевой прозрачности и правильном разделении обязанностей между клиентом и сервером.
>> а почему они не обходятся?
>> если более сложные игры гоняя картинку в видяшку умудряются обходится всего лишь
>> командами опенгл, а не гонять только битмапы
> Не хотят. Дело, может быть, не в том, что архитектура иксов непригодна
> для своих задач, а в том, что разработчики тулкитов и приложений
> не нее забили. И что теперь делать? Вы все равно не
> заставите всех разработчиков библиотек и приложений (тем более кроссплатформенных) думать
> о сетевой прозрачности и правильном разделении обязанностей между клиентом и сервером.неужели если тулкит будет учитывать иксы - он не станет быстрее на иксах ? если переложит часть своей внутренней реализации отрисовки на сами иксы когда запущен поверх иксов
реализацию тредов же тулкиты не свою таскают, а юзают системную
> почему так?Потому что они рендерят битмап и отдают иксам битмап. Не умеют встроенные фичи иксов делать вменяемый рендер который бы устроил пользователей в XXI веке. К тому же даже тяжелый рендер в либе не ставит колом всю графику "глобально". Как максимум свою программу. А если иксы надолго займутся рендером "всех наворотов в вон той клевой программе" - весь мир подождет. И юзер будет дико беситься на полностью заклиненой системе, дергающейся хуже win95.
Более того - если даже 5 разных программ займется активным рендером себя любимых в либе тулкита, они легко и естественно отмасштабируются по ядрам CPU. Сами. Как побочный эффект. Пять процов будут рюхать 5 программ.
А чтобы так же по ядрам проца отмасштабировался рендер в иксах... у... для этого скромный спейсшаттл надо превратить в убийцу планет. А людишки даже с обслуживанием шаттлов напрягаются ужасно, так что об этом речь не идет.
В общем, по факту иксы - хреновая рисовалка битмапов и хреновая рендерилка. При адовом объеме кода.
>[оверквотинг удален]
> системе, дергающейся хуже win95.
> Более того - если даже 5 разных программ займется активным рендером себя
> любимых в либе тулкита, они легко и естественно отмасштабируются по ядрам
> CPU. Сами. Как побочный эффект. Пять процов будут рюхать 5 программ.
> А чтобы так же по ядрам проца отмасштабировался рендер в иксах... у...
> для этого скромный спейсшаттл надо превратить в убийцу планет. А людишки
> даже с обслуживанием шаттлов напрягаются ужасно, так что об этом речь
> не идет.
> В общем, по факту иксы - хреновая рисовалка битмапов и хреновая рендерилка.
> При адовом объеме кода.можете прокомментировать это? https://www.opennet.ru/openforum/vsluhforumID3/114049.html#120
А осом в этом вашем вяленом работает?!
Нет, но есть (или ещё не совсем?) http://way-cooler.org/. Вроде как его автор хотел запилить совместимость с овсом на уровне lua api.
В том и дело, что осома свое АПИ есть, без необходимости велосипедить на голом луа (хотя… можно и повелосипедить).
имелось ввиду на уровне lua api awesome-a
> Еще лет 10 разработки и "золотой ключик у нас в кармане".Линус сказал, ещё 25 лет можно ждать. Лично я уже оставляю это потомкам (которых у меня лично нет).
> Смена номера версии Weston на 4.0 обусловлена изменениями ABI, нарушающими совместимостьПрекрасно, просто прекрасно. Они ещё не взлетели как следует, а уже кладут болт на совместимость, что лишь увеличивает процент неопределённости - а надо ли разрабатывать под этотй ой-вей-ленд, а то через неделю бац и мою программу придётся опять переписывать.
>> Смена номера версии Weston на 4.0 обусловлена изменениями ABI, нарушающими совместимость
> Прекрасно, просто прекрасно. Они ещё не взлетели как следует, а уже кладут
> болт на совместимость, что лишь увеличивает процент неопределённости - а надо
> ли разрабатывать под этотй ой-вей-ленд, а то через неделю бац и
> мою программу придётся опять переписывать.наоборот, лучше на взлёте ломать чтоб кости прямые были
а может кто рассказать почему тех же Qt и Gtk не заставили в X-овом бэкенде отказаться от гоняния битмапов ? видь в иксах есть механизм передачи графики на языке примитивов с отрисовкой уже иксами, есть сервер шрифтови почему нельзя те же Qt разбить на часть что рисует примитивы и на саму рисовалку примитивов в видеопамять ?
> а может кто рассказать почему тех же Qt и Gtk не заставили
> в X-овом бэкенде отказаться от гоняния битмапов ? видь в иксах
> есть механизм передачи графики на языке примитивов с отрисовкой уже иксами,
> есть сервер шрифтов
> и почему нельзя те же Qt разбить на часть что рисует примитивы
> и на саму рисовалку примитивов в видеопамять ?почему нельзя рисовать обычный интерфейс в терминах аналога языка OpenGl - подгрузи текстурку один раз и отрисовывай ей линию
видь игроделы как-то умудрились догадаться что ненужно каждый раз гонять в видеопамять битмапы, что надо слать команды в видяху, а не видеопоток, как почему-то гонят приложения иксам
кстати, госопода эксперты, кто может прокомментировать?цитата:
>Отсюда все "сложности" с производительностью (и двойная буферизация — один
> битмап у клиента, второй у сервера). И как раз в этом
> месте пресловутая сетевая прозрачность даёт сбои. Ну как сбои... "сложности" с
> производительностью, вызванные необходимостью прокачивать битмапы по сети.Что за бред? Ты вообще не знаешь как устроены иксы и что-то пытаешь здесь объяснить. Первое, все битмапы хранятся _только_ на сервере. Клиент получает лишь ссылки на них. Для обработки самих битмапов на стороне клиента действительно нужно создавать копию, т.к. сервер клиенту не отсылает никаких данных самого битмапа (см. выше). Сама обработка битмапов на стороне клиента нужна исключительно в особых случаях, и к ним не относится вывод стандартных окошек. Для ряда манипуляций над битмапами имеются расширения иксов, которые также исполняются на стороне сервера также эффективно как будь эти манипуляции на стороне клиента.
Поэтому основная проблема в том, что никто не хочет писать расширения для иксов. Все хотят переносить свои приложения на DirectX/OpenGL не написан ни строчки кода для иксов. Или проще говоря, делать все на клиенте. Большинство таких приложений это игры, в меньшинстве специализированный софт для обработки компьютерной графики. Стандартные приложения от иксов как работали хорошо так и будут работать хорошо, т.к. они используют примитивы самого сервера (иксового или вейленда).
https://www.opennet.ru/openforum/vsluhforumID3/111940.html#138
> а может кто рассказать почему тех же Qt и Gtk не заставили
> в X-овом бэкенде отказаться от гоняния битмапов ? видь в иксах
> есть механизм передачи графики на языке примитивов с отрисовкой уже иксами,
> есть сервер шрифтовИ работает это все мягко говоря не соответствуя пожеланиям авторов либ и программ.
Более того, когда какая-то программа делает что-то ресурсоемкое - при таком дизайне системы все остальное может встать раком.
Ну вот например, шрифты. Если делать их нормально, с хинтингом, антиалиасингом и вообще, не делая вид что на дворе 90-е, рендер шрифтов занятие довольно ресурсоемкое на самом деле.
Допустим в графический терминал начали сыпаться гигазы логов. Если терминал при этом упрется в проц в либе рендера TTF фонтов - да и болт с ним, потупит и прочухается. А если это будет сервер фонтов - во всей системе на 5 минут встанет колом графика, потому что программа терминала делает тяжелючие вызовы в иксы и те усиленно рендерят фонты.
Мало того что это будет тормознее, это еще и вклинит всю графику в системе. О таких вещах как арбитраж ресурсов в таких ситуациях в иксах не особо задумывались. И поэтому все может стать настолько плохо что у юзера даже менеджер задач не отрисуется чтобы процесс вылящий гигазы в терминал или терминал прибить.
Нафига такая графическая подсистема кому-то будет нужна? Кроме узкой касты эстетов с графикой уровня VESA.