Исправление
geekless,
(текущая версия)
:
Ну ты более в теме обсуждения, потому что я патчингом занимался достаточно давно, а ты, видимо, попозжее.
(устало) Патчингом чего ты занимался?
Aceler, ты ни на одно моё сообщение по существу не ответил. Неудобные или непонятные абзацы ты просто пропускаешь и начинаешь дальше гнуть в своем духе.
Вот насчёт аргумента, что в windows принудительная перерисовка окна никуда не делась и никому не мешает ты что ответил? Ничего. На вопрос, какой реальный объем упрощения кода что ответил? Что не знаешь.
Возьмём вот эту твою реплику:
Всё, кроме OpenGL — это то самое API для рисования в прямоугольники, которые затем сшивает композитор. Именно так работает композитный режим в Xorg. Только там ещё куча вызовов обрабатывается, которые в композитном режиме совсем не нужны и не будут вызваны, но требуются по спецификации X.
Ты пишешь ерунду. Которая показывает, что об устройстве иксов ты не знаешь даже на уровне протокола ничего. Сделать тебе ликбез? Изволь: в X11 имеется три равноправных API для рисования: OGL, Xrender и рисующее API в Core Protocol. Равноправных. Все они рисуют на объектах типа drawables. Частный случай таких объектов: окна. Все они рисуют «прямоугольники» (окна!), «которые затем сшивает композитор». Да, и OGL тоже.
(Вру, кроме этих трех, есть еще расширения для вывода видео, но для упрощения изложения можно их не рассматривать.)
Композитному менеджеру не важно, каким из трех API нарисована картинка. Хоть всеми тремя сразу. Он получает damage-события от drawables, на которые подписан, и перерисовывает свой собственный drawable (рутовое окно). Это единственное, чем занят композитный менеджер. Механизмы рисования и механизм композитинга полностью развязаны и никак друг на друга влияния не оказывают.
Только там ещё куча вызовов обрабатывается, которые в композитном режиме совсем не нужны и не будут вызваны, но требуются по спецификации X.
Какая «куча вызовов» «обрабатывается»? Ты можешь эту кучу показать с исходниками сервера и спецификациями протокола в руках и продемонстрировать наличие в ней хотпоинтов с профайлером в руках? Уверен, что не можешь, и ты этим не занимался. Просто опять, как и во всех случах ранее, «где-то что-то слышал».
О чем тут говорить? Я рассуждаю как человек, который со всем, о чем говорит, либо работал, либо, как минимум, внимательно читал документацию, и как человек, который потенциально готов это разрабатывать. А ты рассуждаешь как кто-то, кто начитался ерунды типа той, что послужила причиной создания этого треда.
Исходная версия
geekless,
:
Ну ты более в теме обсуждения, потому что я патчингом занимался достаточно давно, а ты, видимо, попозжее.
(устало) Патчингом чего ты занимался?
Aceler, ты ни на одно моё сообщение по существу не ответил. Неудобные или непонятные абзацы ты просто пропускаешь и начинаешь дальше гнуть в своем духе.
Вот насчёт аргумента, что в windows принудительная перерисовка окна никуда не делась и никому не мешает ты что ответил? Ничего. На вопрос, какой реальный объем упрощения кода что ответил? Что не знаешь.
Возьмём вот эту твою реплику:
Всё, кроме OpenGL — это то самое API для рисования в прямоугольники, которые затем сшивает композитор. Именно так работает композитный режим в Xorg. Только там ещё куча вызовов обрабатывается, которые в композитном режиме совсем не нужны и не будут вызваны, но требуются по спецификации X.
Ты пишешь ерунду. Которая показывает, что об устройстве иксов ты не знаешь даже на уровне протокола ничего. Сделать тебе ликбез? Изволь: в X11 имеется три равноправных API для рисования: OGL, Xrender и рисующее API в Core Protocol. Равноправных. Все они рисуют на объектах типа drawables. Частный случай таких объектов: окна. Все они рисуют «прямоугольники» (окна!), «которые затем сшивает композитор». Да, и OGL тоже.
(Вру, есть еще расширения для вывода видео, но для упрощения изложения можно их не рассматривать.)
Композитному менеджеру не важно, каким из трех API нарисована картинка. Хоть всеми тремя сразу. Он получает damage-события от drawables, на которые подписан, и перерисовывает свой собственный drawable (рутовое окно). Это единственное, чем занят композитный менеджер. Механизмы рисования и механизм композитинга полностью развязаны и никак друг на друга влияния не оказывают.
Только там ещё куча вызовов обрабатывается, которые в композитном режиме совсем не нужны и не будут вызваны, но требуются по спецификации X.
Какая «куча вызовов» «обрабатывается»? Ты можешь эту кучу показать с исходниками сервера и спецификациями протокола в руках и продемонстировать наличие в ней хотпоинтов с профайлером в руках? Уверен, что не можешь, и ты этим не занимался. Просто опять, как и во всех случах ранее, «где-то что-то слышал».
О чем тут говорить? Я рассуждаю как человек, который со всем, о чем говорит, либо работал, либо, как минимум, внимательно читал документацию, и как человек, который потенциально готов это разрабатывать. А ты рассуждаешь как кто-то, кто начитался ернуды типа той, что послужила причиной создания этого треда.