После полутора лет разработки представлен (http://lists.x.org/archives/xorg-announce/2012-June/001977.html) релиз X.Org 7.6 (http://www.x.org/wiki/Releases/7.7) (X11R7.7), выпущенный в канун празднования двадцатипятилетия X11R1 (X Window System Version 11, Release 1), выпущенного 15 сентября 1987 года.
X.Org 7.7 официально поддерживает платформы Linux, BSD, Solaris, MacOS X, Windows и GNU Hurd. В новую версию вошли наработки, ранее представленные в релизах X Server 1.10 (http://www.opennet.me/opennews/art.shtml?num=29730), 1.11 (http://www.opennet.me/opennews/art.shtml?num=31608) и 1.12 (http://www.opennet.me/opennews/art.shtml?num=33265). В состав также включены свежие версии развиваемых смежно драйверов и библиотек. Среди добавленных улучшений отмечается поддержка обработки мультитач событий, переработка документации, поддержка плавной прокрутки, включение подсистемы синхронизации X Synchronization Fences, дополнительные средства управления перемещением курсора.Наиболее интересные новшества (http://www.x.org/releases/X11R7.7/doc/xorg-docs/ReleaseNotes...) X.Org 7.7:
- Реализация протокола Multitouch, описывающего методы взаимодействия между X Window System, мультитач-устройствами и пользовательскими приложениями. Протокол позволяет организовать передачу и раздельную обработку событий, связанных с одновременными касаниями к тачпадам или сенсорным экранам. Поддерживается два класса мультитач-устройств: устройства с прямым мультитач-режимом, такие как сенсорные экраны, которые отличаются поддержкой нескольких независимых точек касания, каждая из которых может возникнуть в любом месте экрана и чаще всего является прямым касанием, и устройства с косвенным мультитач-режимом, такие как тачпады, которые отличаются тем, что независимые точки касания могут интерпретироваться относительно текущей позиции указателя и чаще всего связаны с вводом управляющего жеста.
Кроме того, реализована эмуляция нескольких указателей для избранных событий, а также механизмы для перехвата и переотправки управляющих последовательностей, связанных с касаниями к экрану. Изменения с поддержкой мультитач добавлены в X-сервер, расширение X Input 2.2, драйвер xf86-input-evdev, библиотеку libXi и другие сопутствующие компоненты;- Дополнительные улучшения, представленные в расширении Xinput, позволили реализовать (http://who-t.blogspot.com/2011/09/whats-new-in-xi-21-smooth-...) для тачпадов режим плавной прокрутки и улучшенные методы прогнозирования движения, позволяющие игнорировать случайные перемещения и более точно отслеживать управляющие прикосновения. Также добавлена возможность отслеживания клиентом raw-событий, генерируемых устройствами ввода;
- Интеграция кода новой улучшенной подсистемы синхронизации X Synchronization Fences, разработанной компанией NVIDIA и позволяющей организовать синхронизацию формирования вывода на базе протокола X11 с клиентами, поддерживающими прямой рендеринг (DRI), такими как OpenGL. В частности, X Synchronization Fences можно использовать для синхронизации обновлений экрана в базирующихся на OpenGL композитных менеджерах со стандартным рендерингом X-сервера (сейчас в композитных менеджерах для совмещения X11-вывода с итоговым изображением приходится использовать двойную буферизацию). Поддержка X Synchronization Fences добавлена в API libxcb-sync и libXext;
- В расширение X Fixes 5.0 добавлена поддержка границ указателя (Pointer barriers), позволяющих приложению определять дополнительные ограничения на перемещения курсора в определённой области. Подобное может быть использовано композитными менеджерами и десктоп-окружениями при выводе фиксированных элементов интерфейса в определённой области экрана, например, в левом верхнем углу, при этом данная область должна быть непроницаема и в многомониторных конфигурациях;
- В библиотеки XCB (X protocol C-language Binding) началось добавление поддержки расширений GLX и XKB. В настоящее время работа ещё полностью не завершена и через XCB API доступна лишь часть возможностей GLX и XKB. Библиотеки XCB, идущие на смену Xlib, отличаются небольшим размером, пониженным потреблением памяти, минимизацией задержек, поддержкой асинхронных запросов, предоставлением прямого доступа к протоколу X11, изначальной поддержкой многопоточных программ и высокой расширяемостью (для описаний расширений X-протокола вместо M4 используется XML);
- Проведена реструктуризации документации (http://www.x.org/wiki/Development/Documentation/WritingDocum...). Спецификации на библиотечные вызовы и протокол теперь представлены в едином формате DocBook XML с определением ссылок между документами, вместо набора хаотичного набора файлов в разных форматах;
- Обновлены (http://www.x.org/releases/X11R7.7/src/driver/) входящие в комплект видеодрайверы и драйверы устройств ввода: xf86-video-intel 2.19 (http://www.opennet.me/opennews/art.shtml?num=33756), xf86-video-ati 6.14.4 (http://www.opennet.me/opennews/art.shtml?num=33483), xf86-video-openchrome 0.2.906, xf86-video-sis 0.10.4, xf86-video-cirrus 1.4.0, xf86-input-vmmouse 12.8.0, xf86-input-synaptics 1.6.1, xf86-input-mouse1.7.2, xf86-input-keyboard 1.6.1, xf86-input-evdev 2.7.0. Добавлен новый драйвер xf86-video-vmware 12.0.2 (http://www.opennet.me/opennews/art.shtml?num=33327) с поддержкой архитектуры акселерации vmwgfx, позволяющей использовать 2D-акселерацию в гостевых Linux-системах, работающих под управлением продуктов виртуализации VMware.
URL: http://lists.x.org/archives/xorg-announce/2012-June/001977.html
Новость: http://www.opennet.me/opennews/art.shtml?num=34037
>Интеграция кода новой улучшенной подсистемы синхронизации X Synchronization FencesЭто позволит получить в X11 всё что планировалось в вейланде?
Вы о двойной буфферизации? Думаю да, но, оно не поможет избавится от самого протокола Х11... Тоесть, плавного ресайзах на тяжёлых окнах видеть не прийдётся...
> прийдётся...А также культурного уровня нагрузки на CPU при интенсивном выводе графики...
> Вы о двойной буфферизации? Думаю да, но, оно не поможет избавится от
> самого протокола Х11... Тоесть, плавного ресайзах на тяжёлых окнах видеть не
> прийдётся...Ну и чёрт с ним, с "плавным ресайзом".
> Ну и чёрт с ним, с "плавным ресайзом".Да и вообще, нафиг прямые и правильные решения. Кривые и тормозные костыли рулят!
> Да и вообще, нафиг прямые и правильные решения. Кривые и тормозные костыли
> рулят!Откуда вы взяли, что Wayland - прямое решение?
А что в вайленде кривое и тормозное?
А что прямое и стремительное? Обещают много да, но ты у мамки папки спроси в твоей стране коммунизЬм обещали ... релиз уже задержался на ~32 года :)
Что тормозное - не знаю. А криво то, что Wayland, который в качестве прослойки между Х и железом вполне на месте, пытаются запихнуть вместо Х. И этим убивают всю архитектуру Х.Элементарный взгляд на проблему вывода данных на графический экран говорит, что должны быть выделены части:
1. Драйвера мыши, клавиатуры, видеокарты.
2. Прорисовщик низкоуровневых примитивов, который переводит удобные команды типа MoveTo/LineTo в команды драйвера.
3. Менеджер окон.
4. Менеджер разделяемых ресурсов - курсоры, шрифты и т.д.
5. База библиотек управляющих компонент.
6. Библиотека управляющих компонент - строится на 5.
И вот эта структурированность в архитектуре Х присутствует. А Wayland'описатели предлагают пункты 2-6 засунуть в библиотеку компонент и каждому, создающему библиотеку кнопочек, лепить свой велосипед.
Ну покажите тогда как будет в Wayland проброс по сети происходить. Я, например, регулярно использую данный функционал.
> Вы о двойной буфферизации? Думаю да, но, оно не поможет избавится от
> самого протокола Х11... Тоесть, плавного ресайзах на тяжёлых окнах видеть не
> прийдётся...1). Много ошибок
2). Плавный ресайз окон есть, и всегда был. http://zenitur.narod.ru/resize-okna-v-KDE3.mkv
вы бы еще изменение размера окна pcmanfm'a выложили
> вы бы еще изменение размера окна pcmanfm'a выложилиА нужно обязательно выкладывать видео программ сделанных через попу?
>> Вы о двойной буфферизации? Думаю да, но, оно не поможет избавится от
>> самого протокола Х11... Тоесть, плавного ресайзах на тяжёлых окнах видеть не
>> прийдётся...
> 1). Много ошибок
> 2). Плавный ресайз окон есть, и всегда был. http://zenitur.narod.ru/resize-okna-v-KDE3.mkvА покажите тоже самое, только на примере Хрома/Файрфокса или чего нибудь подобного с каким нибудь открытым сайтом в нем(opennet, к примеру).
Так а откуда вы взяли, что проблема именно в Х? Проблема-то в том, что при изменении окна браузер должен перевёрстывать текст. Это занимает определённое время, и никакая буферизация, пусть даже четверная, тут не поможет.
> Так а откуда вы взяли, что проблема именно в Х? Проблема-то в
> том, что при изменении окна браузер должен перевёрстывать текст. Это занимает
> определённое время, и никакая буфферизация, пусть даже четверная, тут не поможет.Собственно, проблема медлительности прорисовки при изменении размера решена ещё в twm. Решение заключается в том, что при изменении размера перерисовывается каркас окна, а не само окно.
> Собственно, проблема медлительности прорисовки при изменении размера решена ещё в twm.
> Решение заключается в том, что при изменении размера перерисовывается каркас окна,
> а не само окно.проблема в том, что при этом «грабится» сервер, емнип. поэтому другие окна радостно ждут, пока сервер отпустят, и не обновляются. а если сервер не «грабить», могут полезть артефакты от каркаса.
и это действительно решается только двойной буферизацией. увы.
> и это действительно решается только двойной буферизацией. увы.Безусловно, двойная буферизация во многом помогает. Но далеко не везде. Как вы не буферизуйте, при растягивании окна ФФ на сложных страницах обязательно полезут артефакты внутри окна.
это понятно, но мы (я) не совсем про это уже. просто заметил, что остальные окна тоже «замирают». и вот на этом факте можно было бы сыграть, но собеседник отчего-то не стал.
> это понятно, но мы (я) не совсем про это уже. просто заметил,
> что остальные окна тоже «замирают». и вот на этом факте можно
> было бы сыграть, но собеседник отчего-то не стал.Вообще говоря, нужно, конечно, делать прорисовщик в Х многопоточным, с двойной буферизацией и т.д. :-( Более того, желательно обновить набор примитивов, ввести что-то типа шейдеров, добавить видеокодек, чтобы не гонять разжатое видео по сети, добавить аудио и Хprint.
> Вообще говоря, нужно, конечно, делать прорисовщик в Х многопоточнымну, тут многопоточность никак не поможет: окна «замерли» потому, что им запретили рисоваться. чтобы артефактов не наделать.
а в многопоточном отрисовщике толку очень мало: видеокарта-то одна всё равно.
IMHO, почему хорошо когда все тулкиты будут на OpenGL, потому что вот:
http://www.youtube.com/watch?v=S6OTcEpEqOs
По моему, проблема не в изменении размеров окна, а в перестройке элементов интрфейса, потому как размеры окон вместе с содержимым меняются просто превосходно. А вот когда встает вопрос о перегенереции содержимого (типа страницы сайта), тогда и возникают проблемы, но это совсем не зависит ни от X'ов, ни от видеокарты.
> IMHO, почему хорошо когда все тулкиты будут на OpenGL, потому что вот:В каком смысле, тулкиты на OpenGL? Вы имеете ввиду, что в Х Сервер будут посылаться примитивы OpenGL?
> а в многопоточном отрисовщике толку очень мало: видеокарта-то одна всё равно.Между прочим, видеокарта тоже может выполнять многопоточные приложения.
это, имо, добавит больше проблем, чем решит — с синхронизацией всякой.
> Так а откуда вы взяли, что проблема именно в Х? Проблема-то в
> том, что при изменении окна браузер должен перевёрстывать текст. Это занимает
> определённое время, и никакая буферизация, пусть даже четверная, тут не поможет.Да, затупил малость.
> Вы о двойной буфферизации? Думаю да, но, оно не поможет избавится от
> самого протокола Х11... Тоесть, плавного ресайзах на тяжёлых окнах видеть не
> прийдётся...Что есть "плавный ресайз" и что есть "тяжелые окна"?
> Это позволит получить в X11 всё что планировалось в вейланде?Сложно сделать из ломовой лошади беговую клячу.
А там что-то планировалось сделать 0_o
Отличная новасть про иксы..... и как уже не странно, в первом же комменте detected слово вэйлэнд %))
нужно же предворять начало спец.олимпиады какими-то словами
Здесь инструкции для желающих потестить Xorg 7.7 в FreeBSD, ну или для тех, кто не в состоянии потерпеть две недели :)
http://lists.freebsd.org/pipermail/freebsd-ports/2012-June/0...
Too late.
Wayland in the way...
да идите уже к своему вяленому. ну, нужен вам этот огрызок — используйте и радуйтесь. однако ж всенепременно надо прийти к иксам и рассказать, как будет круто, когда… ребят, это называется «зависть».
> да идите уже к своему вяленому. ну, нужен вам этот огрызок —Ну ну... Если вяленое пилят то выходит что он тоже кому то нужен.
Ну и в первую очередь он нужен самим иксам. Простой пример - не было бы гнома мы до сих пор бы сидели на второкедах. Конкуренция сестра прогресса.
> Ну ну… Если вяленое пилят то выходит что он тоже кому то
> нужен.а я разве сказал «никому не нужен»? O_O
пусть себе пилят, жалко, что ли. лично мне он не нужен, да — потому что там нет кучи полезных фич. я таки об этом говорю в темах о вяленом, и краткий список приводил. фанбои же вяленого способны только на «иксы старые, вяленый крут!» на сравнение у них уже не хватает знаний.> Ну и в первую очередь он нужен самим иксам.
ага. как строителю бантик.
> не было бы гнома мы до сих пор бы сидели на
> второкедах.орли? и ты можешь это доказать? или так, спекулируешь?
кстати, а что такого плохого во «второкедах»? или ты намекаешь на то, что кеды — как и гном — с каждым релизом всё жирней и невнятней? так вряд ли в этом гном виноват.> Конкуренция сестра прогресса.
между вяленым и иксами нет конкуренции, и быть её не может: это совершенно разные системы. с разной идеологией и с разной ЦА.
Бред сивой К. Qt движется и кеды были бы вынуждены двигаться.
Гыгы. On the way. In the way значит "мешается". Эти мне знатоки английского... :)
> Эти мне знатоки английского…ну так… гуглопереводчик во все поля. это если вообще хватает сил на гуглопереводчик.
> Гыгы. On the way. In the way значит "мешается". Эти мне знатоки
> английского... :)У Нирваны есть песня "Something in the way", переводится как "нечто уже в пути",
т.е. Курт позвонил барыге и сидел ждал, а оно ехало.
Ну или еще у Ноля песенка была "доктор едет-едет" - из той же оперы )Вобщем, английский это такая гибкая штука ))
>> Гыгы. On the way. In the way значит "мешается". Эти мне знатоки
>> английского... :)
> У Нирваны есть песня "Something in the way", переводится как "нечто уже
> в пути",
> т.е. Курт позвонил барыге и сидел ждал, а оно ехало.
> Ну или еще у Ноля песенка была "доктор едет-едет" - из той
> же оперы )
> Вобщем, английский это такая гибкая штука ))"Что-то НА пути" переводится это, падаван юный. Английский учить надо тебе и яду выпить.
> "Что-то НА пути"На какой планете учил английский ты, о джедай?
> яду выпить.
Боюсь я, темная сила овладевает тобою.
Мне очень понравилась теория Wayland. И очень приятно видеть развитие X.
Тут ситуация какая - Gnome 2 и KDE 3.5 работали ну просто великолепно.
Почему же со временем все изменилось? Да очень просто основа тех систем была 2D отрисовка, а с этим X прекрасно справлялся. Когда начали нагружать OpenGL и тут начались проблемы...
Современные компьютеры способны с легкостью справляться с "красивостями", а X - нет.
Вот и пробуют решить эту задачу другим путем:
оборудованием полностью пусть занимается ядро (оно для этого то и нужно), а напишем простой обработчик для графики.
Х же чем только не занимается....
Оба проекта нужны и будут востребованы скорее всего. А вот как будет на самом деле время покажет.
осталось прояснить один вопрос, который все как-то скромно обходят стороной: чем была плоха эта самая «2д-отрисовка»-то? всё, что есть Кардинально Нового во всяких анимациях — это замедление взаимодействия с компом. если без анимации я ТЫЦ! окно РАЗ! и всё, то с анимацией я ТЫЦ! окно «ыыыыы… хряяяаааап… кряаааак…» и всё это время ругаешься матом, потому что уже успел бы что-то в окне сделать.
>что есть Кардинально Нового во всяких анимацияхэто красиво.
>>что есть Кардинально Нового во всяких анимациях
> это красиво.спорный вопрос. для меня вот «красиво» то, что функционально. интерфейс, замедляющий моё взаимодействие с техникой, нефункционален. а потому некрасив.
а ещё это нарушает одно из правил хорошего интерфейса: быть незаметным. пользователь ведь (обезьян не рассматриваем) не ради интерфейса софт запускает, а чтобы решить какую-то свою задачу.
> это красиво.Есть масса вариантов сделать "красиво". Например, вот вам красивая строгая графика OpenLook - http://www.catb.org/~esr/writings/taouu/html/graphics/olwm.png
1990-й год, между прочим.
нененене. не блестит, не переливается, анимации нет — это некрасиво!
> нененене. не блестит, не переливается, анимации нет — это некрасиво!Анимация есть, но её очень мало. Удивительно то, что после OpenLook очень долгое время не было ничего мало-мальски симпатичного. В SUN его променяли на уродливый Motif.
Впрочем, я буквально на днях играл с Е17. Вот там - действительно, всё блестит и анимируется. Причём не слишком навязчиво, и очень мало жрёт ресурсов.
У нас разные понятия о красивости.
> "красиво". Например, вот вам красивая строгая графика OpenLookСлово красиво тут действительно надо в кавычки брать. Иксы годятся только как пришлепка к Wayland - в таком виде они и будут жить дальше на радость староверам :)
Вообще-то, при использовании OpenGL, процедура "я ТЫЦ! окно РАЗ! и всё" - происходит гораздо БЫСТРЕЕ и без стопроцентной нагрузки на CPU, что благоприятно сказывается и на общей производительности системы - т.е. если на одном мониторе работает какой-то динамический контент, а над другом происходят какие-то манипуляции с окнами, то это ни как не скажется на других окнах/задачах, в отличии от старой 2D отрисовки процессором. Ну а если у вас включены «ыыыыы… хряяяаааап… кряаааак…» то - кто же вам виноват?
отвечу заодно и анониму ниже: и с какого это испугу быстрее? по пунктам, пожалуйста. можно по отношению к вяленому, можно по отношению к иксам.хинт: количество софта, использующего OpenGL для отрисовки *контента* окна невелико — в основном это игрушки.
хинт: в иксах это убивает сетевую прозрачность (не то, чтобы совсем уж убивает, но…)
хинт: современные видеокарты умеют ускорять 2д-операции (и иксы этим пользуются).
хинт: в иксах всё это всё равно убивается «композитными менеджерами». что будет в вяленом — пока знает только мохнатый мудрец.
> хинт: количество софта, использующего OpenGL для отрисовки *контента* окна невелико —
> в основном это игрушки.- QT4 тулкит полностью может рендериться через OpenGL.
- Оконные менеджеры Kwin,Compiz. При манипуляциях с окнами содержимое в них не фиксируется и не покрывается артефактами, как при 2d: если это, например, видео - оно продолжает отображаться, без единой запинки, при любых манипуляциях(трансформация, перемещение, развороты в 3D плосокости); если это любое другое содержимое (динамические графики, вебстраницы и прочее) - оно продолжает отображаться, без остановки, при любых манипуляциях. Сюда же замечу - динамическое масштабирование, алфаканалы, повороты окон(полезно для верстки, и соответсвующего монитора с поворотом).> хинт: в иксах это убивает сетевую прозрачность (не то, чтобы совсем уж
> убивает, но…)Вы когда-нибудь запускали 3D шуттер по сети?.. Я запускал... Клинт на машине без OpnGL, сервер на мощной машине с Nvidia - без единого тормоза - fps зависти от видеокарты а не сети. Потому как OpenGL примитивы, по сети, летают просто превосходно.
> хинт: современные видеокарты умеют ускорять 2д-операции (и иксы этим пользуются).
Ага, X'ы пользуется - XRender. и на сколько я понимаю - это расширение использует тот же OpеnGL видеокарты (хотя, может и ошибаюсь), только в ограниченном режиме, а не какое-то там отдельное 2D ускорение видеокартой. Например, Kwin поддерживает и OpenGL и XRender, но последний хоть и позволяет использовать кое-какое усокрение и алфаканалы - все равно не сравнимо с OpenGL по скорости и возможностям.
> хинт: в иксах всё это всё равно убивается «композитными менеджерами». что будет
> в вяленом — пока знает только мохнатый мудрец.Эту фразу я вообще не понял. Что именно убивается "композитными менеджерами"? Одновременное использование Compiz/Kwin,VDPAU,XV,OpenGL и все это по сети - не представляет ни каких проблем.
> — QT4 тулкит полностью может рендериться через OpenGL.окошки со стандартными кнопочками и так не тормозят. а если надо рендерить в окне что-то потяжелее — начинают лезть нюансы, и совсем не всегда тормоза связаны с видеоподсистемой.
> — Оконные менеджеры Kwin,Compiz. При манипуляциях с окнами содержимое в них не
> фиксируется и не покрывается артефактами, как при 2dпотому что double buffering. для видео это особо приятно, ага. я что-то похожее в своё время делал для Fluxbox. не понравилось.
> если это, например, видео — оно продолжает отображаться, без единой запинки, при любых манипуляциях(трансформация,
> перемещение, развороты в 3D плосокости)а зачем, кстати, это надо? я вот обычно видео смотрю, а не окном с ним верчу. вопрос, впрочем, не из серии «не надо, выкинуть», просто интересно.
> если это любое другое содержимое (динамические
> графики, вебстраницы и прочее) — оно продолжает отображаться, без остановки, при
> любых манипуляциях.опять же double buffering. это почти то же самое, что grab сервера, только без grab'а, зато с буферизированием (дайте мне медаль за такую идиотскую фразу!).
> Вы когда-нибудь запускали 3D шуттер по сети?..
да. байтораздирающее зрелище.
> OpenGL примитивы, по сети, летают просто превосходно.
так же, как и иксовые. которые точно так же на стороне клиента могут использовать 2д ускорение.
> в ограниченном режиме, а не какое-то там отдельное 2D ускорение видеокартой.
то, что тулкиты предпочитают гонять битмапы, а не использовать иксовые примитивы для отрисовки, ещё не значит, что иксовые драйвера cannot into 2d acceleration. да, набор примитивов у иксов немного устарел, тут спорить не буду.
>> хинт: в иксах всё это всё равно убивается «композитными менеджерами». что будет
>> в вяленом — пока знает только мохнатый мудрец.
> Что именно убивается «композитными менеджерами»?пардон, криво выразился. преимущества использования акселерации. потому что композитные менеджеры вынуждены делать double buffering. не то, чтобы насмерть убивается, конечно, но лишних действий таки добавляет. то, что оно при этом не тормозит, просто показывает уровень развития 3д ускорителей и их умение очень быстро делать blit.
> VDPAU
> и все это по сетиэ… что? я понимаю, что ты тоже криво выразился, но не могу не прицепиться. не обращай внимания.
p.s. Qt, а не QT.
> то, что тулкиты предпочитают гонять битмапы, а не использовать иксовые примитивы для
> отрисовки, ещё не значит, что иксовые драйвера cannot into 2d acceleration.
> да, набор примитивов у иксов немного устарел, тут спорить не буду.А можно ли транслировать примитивы Х в примитивы OpenGL/DirectX? По-идее, примитивы Х должны быть более приспособлены для 2D графики.
> А можно ли транслировать примитивы Х в примитивы OpenGL/DirectX?в гл частично можно. про дх не в курсе, есть ли там вообще хоть что-то кроме блитов.
Дак с 3D то этот "тыц" быстрее будет происходить, ибо через GPU
И, что именно тебе нравится в этой теории? Принцип удушения или средства и способы?
