История изменений

Тогда непонятно, почему ты это отвечаешь на мою реплику «При локальной отрисовке оно должно работать быстрее, чем иксы». Причём здесь реализация ПО, если мы говорим о реализации графической подсистемы?

Я отвечаю на реплику:

Ты предлагаешь принести в жертву локальную отрисовку ради сетевой?

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

Тот же OGL является полностью network-agnostic. Когда приложение получает контекст OGL и начинает отправлять ему команды, оно понятия не имеет, что это за сущность такая и где она находится. И не имеет никакой возможности это узнать.

Всё, что происходит, когда ты в приложении вызываешь, например, glBindTexture, лежит полностью на совести реализации.

И если мы в эту реализацию заглянем, то для современного ускорителя обнаружим там механику похлеще иксового протокола. В некотором роде, там тоже имеется аналог сети. Команды OGL трансформируются в драйверо-зависимый формат и в виде пакетов посылаются средствами аппаратной платформы в видеокарту. Как и в случае с сетью, приемлимую производительность мы получим только если мы хорошо нагружаем канал, и у нас нет раунд-трипов: не требуется чтение данных обратно и синхронизация с состоянием видеокарты.

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

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

Я ж там и привёл аргументы, что в вейланде сделано по-другому и никто никому ничего не должен.

Тут стоило бы уточнить, что такое «аргумент». Потому что фраза, на которую ты ответил «нет», была: «Разделение клиент-сервер должно проходить именно по линии рисующего API» в том смысле, что это наиболее эффективный способ. И наличие вейланда никак не служит аргументом в пользу того, что указанный способ не самый эффективный.

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

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

Ты почему-то сосредоточился на одной задаче графического сервера — сетевой. И в упор не видишь всего остального. Поэтому единственное что я могу предложить — дождаться реализации и пощупать преимущества своими руками.

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

Во-вторых. Я сосредотачиваюсь не на поддержке сети, а на грамотной архитектуре современного графического стека, который может обеспечить гибкость и расширяемость в будущем. Разные уровни абстракции должны быть развязаны друг с другом - это аксиома. Возможность сетевого рендеринга всего лишь лакмусовая бумажка: если уж даже от того, что уже 30 лет существует, архитектура не позволяет абстрагироваться, то как она будет абстрагироваться от новых условий, которые возникнут в будущем? Методом порождения костылей и костылей на костылях?

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

Это не серверу должно быть пофиг. Это как раз клиенту на всё должно быть пофиг. Для клиента должно быть стабильное рисовательное API. А каким раком встанет сервер, это уже детали реализации.

Тогда непонятно, почему ты это отвечаешь на мою реплику «При локальной отрисовке оно должно работать быстрее, чем иксы». Причём здесь реализация ПО, если мы говорим о реализации графической подсистемы?

Я отвечаю на реплику:

Ты предлагаешь принести в жертву локальную отрисовку ради сетевой?

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

Тот же OGL является полностью network-agnostic. Когда приложение получает контекст OGL и начинает отправлять ему команды, оно понятия не имеет, что это за сущность такая и где она находится. И не имеет никакой возможности это узнать.

Всё, что происходит, когда ты в приложении вызываешь, например, glBindTexture, лежит полностью на совести реализации.

И если мы в эту реализацию заглянем, то для современного ускорителя обнаружим там механику похлеще иксового протокола. В некотором роде, там тоже имеется аналог сети. Команды OGL трансформируются в драйверо-зависимый формат и в виде пакетов посылаются средствами аппаратной платформы в видеокарту. Как и в случае с сетью, приемлимую производительность мы получим только если мы хорошо нагружаем канал, и у нас нет раунд-трипов: не требуется чтение данных обратно и синхронизация с состоянием видеокарты.

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

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

Я ж там и привёл аргументы, что в вейланде сделано по-другому и никто никому ничего не должен.

Тут стоило бы уточнить, что такое «аргумент». Потому что фраза, на которую ты ответил «нет», была: «Разделение клиент-сервер должно проходить именно по линии рисующего API» в том смысле, что это наиболее эффективный способ. И наличие вейланда никак служит аргументом в пользу того, что указанный способ не самый эффективный.

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

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

Ты почему-то сосредоточился на одной задаче графического сервера — сетевой. И в упор не видишь всего остального. Поэтому единственное что я могу предложить — дождаться реализации и пощупать преимущества своими руками.

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

Во-вторых. Я сосредотачиваюсь не на поддержке сети, а на грамотной архитектуре современного графического стека, который может обеспечить гибкость и расширяемость в будущем. Разные уровни абстракции должны быть развязаны друг с другом - это аксиома. Возможность сетевого рендеринга всего лишь лакмусовая бумажка: если уж даже от того, что уже 30 лет существует, архитектура не позволяет абстрагироваться, то как она будет абстрагироваться от новых условий, которые возникнут в будущем? Методом порождения костылей и костылей на костылях?

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

Это не серверу должно быть пофиг. Это как раз клиенту на всё должно быть пофиг. Для клиента должно быть стабильное рисовательное API. А каким раком встанет сервер, это уже детали реализации.

Тогда непонятно, почему ты это отвечаешь на мою реплику «При локальной отрисовке оно должно работать быстрее, чем иксы». Причём здесь реализация ПО, если мы говорим о реализации графической подсистемы?

Я отвечаю на реплику:

Ты предлагаешь принести в жертву локальную отрисовку ради сетевой?

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

Тот же OGL является полностью network-agnostic. Когда приложение получает контекст OGL и начинает отправлять ему команды, оно понятия не имеет, что это за сущность такая и где она находится. И не имеет никакой возможности это узнать.

Всё, что происходит, когда ты в приложении вызываешь, например, glBindTexture, лежит полностью на совести реализации.

И если мы в эту реализацию заглянем, то для современного ускорителя обнаружим там механику похлеще иксового протокола. В некотором роде, там тоже имеется аналог сети. Команды OGL трансформируются в драйверо-зависимый формат и в виде пакетов посылаются средствами аппаратной платформы в видеокарту. Как и в случае с сетью, приемлимую производительность мы получим только если мы хорошо нагружаем канал, и у нас нет раунд-трипов: не требуется чтение данных обратно и синхронизация с состоянием видеокарты.

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

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

Я ж там и привёл аргументы, что в вейланде сделано по-другому и никто никому ничего не должен.

Тут стоило бы уточнить, что такое «аргумент». Потому что фраза, на которую ты ответил «нет», была: «Разделение клиент-сервер должно проходить именно по линии рисующего API» в том симысле, что это наиболее эффективный способ. И наличие вейланда никак служит аргументом в пользу того, что указанный способ не самый эффективный.

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

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

Ты почему-то сосредоточился на одной задаче графического сервера — сетевой. И в упор не видишь всего остального. Поэтому единственное что я могу предложить — дождаться реализации и пощупать преимущества своими руками.

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

Во-вторых. Я сосредотачиваюсь не на поддержке сети, а на грамотной архитектуре современного графического стека, который может обеспечить гибкость и расширяемость в будущем. Разные уровни абстракции должны быть развязаны друг с другом - это аксиома. Возможность сетевого рендеринга всего лишь лакмусовая бумажка: если уж даже от того, что уже 30 лет существует, архитектура не позволяет абстрагироваться, то как она будет абстрагироваться от новых условий, которые возникнут в будущем? Методом порождения костылей и костылей на костылях?

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

Это не серверу должно быть пофиг. Это как раз клиенту на всё должно быть пофиг. Для клиента должно быть стабильное рисовательное API. А каким раком встанет сервер, это уже детали реализации.

Тогда непонятно, почему ты это отвечаешь на мою реплику «При локальной отрисовке оно должно работать быстрее, чем иксы». Причём здесь реализация ПО, если мы говорим о реализации графической подсистемы?

Я отвечаю на реплику:

Ты предлагаешь принести в жертву локальную отрисовку ради сетевой?

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

Тот же OGL является полностью network-agnostic. Когда приложение получает контекст OGL и начинает отправлять ему команды, оно понятия не имеет, что это за сущность такая и где она находится. И не имеет никакой возможности это узнать.

Всё, что происходит, когда ты в приложении вызываешь, например, glBindTexture, лежит полностью на совести реализации.

И если мы в эту реализацию заглянем, то для современного ускорителя обнаружим там механику похлеще иксового протокола. В некотором роде, там тоже имеется аналог сети. Команды OGL трансформируются в драйверо-зависимый формат и в виде пакетов посылаются средствами аппаратной платформы в видеокарту. Как и в случае с сетью, приемлимую производительность мы получим только если мы хорошо нагружаем канал, и у нас нет раунд-трипов: не требуется чтение данных обратно и синхронизация с состоянием видеокарты.

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

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

Я ж там и привёл аргументы, что в вейланде сделано по-другому и никто никому ничего не должен.

Тут стоило бы уточнить, что такое «аргумент». Потому что фраза, на которую ты ответил «нет», была: «Разделение клиент-сервер должно проходить именно по линии рисующего API» в том симысле, что это наиболее эффективный способ. И наличие вейланда никак служит аргументом в пользу того, что указанный способ не самый эффективный.

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

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

Ты почему-то сосредоточился на одной задаче графического сервера — сетевой. И в упор не видишь всего остального. Поэтому единственное что я могу предложить — дождаться реализации и пощупать преимущества своими руками.

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

Во-вторых. Я сосредотачиваюсь не на поддержке сети, а на грамотной архитектуре современного графического стека, который может обеспечить гибкость и расширяемость в будущем. Разные уровни абстракции должны быть развязаны друг с другом - это аксиома. Возможность сетевого рендеринга всего лишь лакмусовая бумажка: если уж даже от того, что уже 30 лет существует, архитектура не позволяет абстрагироваться, то как она будет абстрагироваться от новых условий, которые возникнут в будущем? Методом порождения костылей и костылей на костылях?

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

Тогда непонятно, почему ты это отвечаешь на мою реплику «При локальной отрисовке оно должно работать быстрее, чем иксы». Причём здесь реализация ПО, если мы говорим о реализации графической подсистемы?

Я отвечаю на реплику:

Ты предлагаешь принести в жертву локальную отрисовку ради сетевой?

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

Тот же OGL является полностью network-agnostic. Когда приложение получает контекст OGL и начинает отправлять ему команды, оно понятия не имеет, что это за сущность такая и где она находится. И не имеет никакой возможности это узнать.

Всё, что происходит, когда ты в приложении вызываешь, например, glBindTexture, лежит полностью на совести реализации.

И если мы в эту реализацию заглянем, то для современного ускорителя обнаружим там механику похлеще иксового протокола. В некотором роде, там тоже имеется аналог сети. Команды OGL трансформируются в драйверо-зависимый формат и в виде пакетов посылаются средствами аппаратной платформы в видеокарту. Как и в случае с сетью, приемлимую производительность мы получим только если мы хорошо нагружаем канал, и у нас нет раунд-трипов: не требуется чтение данных обратно и синхронизация с состоянием видеокарты.

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

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

Я ж там и привёл аргументы, что в вейланде сделано по-другому и никто никому ничего не должен.

Тут стоило бы уточнить, что такое «аргумент». Потому что фраза, на которую ты ответил «нет», была: «Разделение клиент-сервер должно проходить именно по линии рисующего API» в том симысле, что это наиболее эффективный способ. И наличие вейланда никак служит аргументом в пользу того, что указанный способ не самый эффективный.

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

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

Ты почему-то сосредоточился на одной задаче графического сервера — сетевой. И в упор не видишь всего остального. Поэтому единственное что я могу предложить — дождаться реализации и пощупать преимущества своими руками.

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

Во-вторых. Я сосредотачиваюсь не на поддержке сети, а на грамотной архитектуре современного графического стека, который может обеспечить гибкость и расширяемость в будущем. Разные уровни абстракции должны быть развязаны друг с другом - это аксиома. Возможность сетевого рендеринга всего лишь лакмусовая бумажка: если уж даже от того, что уже 30 лет существует, архитектура не позволяет абстрагироваться, то как она будет абстрагироваться от новых условий, которые возникнут в будущем? Методом порождения костылей и костылей на костылях?

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

Тогда непонятно, почему ты это отвечаешь на мою реплику «При локальной отрисовке оно должно работать быстрее, чем иксы». Причём здесь реализация ПО, если мы говорим о реализации графической подсистемы?

Я отвечаю на реплику:

Ты предлагаешь принести в жертву локальную отрисовку ради сетевой?

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

Тот же OGL является полностью network-agnostic. Когда приложение получает контекст OGL и начинает отправлять ему команды, оно понятия не имеет, что это за сущность такая и где она находится. И не имеет никакой возможности это узнать.

Всё, что происходит, когда ты в приложении вызываешь, например, glBindTexture, лежит полностью на совести реализации.

И если мы в эту реализацию заглянем, то для современного ускорителя обнаружим там механику похлеще иксового протокола. В некотором роде, там тоже имеется аналог сети. Команды OGL трансформируются в драйверо-зависимый формат и в виде пакетов посылаются средствами аппаратной платформы в видеокарту. Как и в случае с сетью, приемлимую производительность мы получим только если мы хорошо нагружаем канал, и у нас нет раунд-трипов: не требуется чтение данных обратно и синхронизация с состоянием видеокарты.

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

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

Я ж там и привёл аргументы, что в вейланде сделано по-другому и никто никому ничего не должен.

Тут стоило бы уточнить, что такое «аргумент». Потому что фраза, на которую ты ответил «нет», была: «Разделение клиент-сервер должно проходить именно по линии рисующего API» в том симысле, что это наиболее эффективный способ. И наличие вейланда никак служит аргументом в пользу того, что указанный способ не самый эффективный.

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

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

Ты почему-то сосредоточился на одной задаче графического сервера — сетевой. И в упор не видишь всего остального. Поэтому единственное что я могу предложить — дождаться реализации и пощупать преимущества своими руками.

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

Во-вторых. Я сосредотачиваюсь не на поддержке сети, а на грамотной архитектуре современного графического стека, который может обеспечить гибкость и расширяемость в будущем. Разные уровни абстракции должны быть развязаны друг с другом - это аксиома. Возможность сетевого рендеринга всего лишь лакмусовая бумажка: если уж даже от того, что уже 30 лет существует, архитектура не позволяет абстрагирвоаться, то как она будет абстрагироваться от новых условий, которые возникнут в будущем? Методом порождения костылей и костылей на костылях?

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

Тогда непонятно, почему ты это отвечаешь на мою реплику «При локальной отрисовке оно должно работать быстрее, чем иксы». Причём здесь реализация ПО, если мы говорим о реализации графической подсистемы?

Я отвечаю на реплику:

Ты предлагаешь принести в жертву локальную отрисовку ради сетевой?

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

Тот же OGL является полностью network-agnostic. Когда приложение получает контекст OGL и начинает отправлять ему команды, оно понятия не имеет, что это за сущность такая и где она находится. И не имеет никакой возможности это узнать.

Всё, что происходит, когда ты в приложении вызываешь, например, glBindTexture, лежит полностью на совести реализации.

И если мы в эту реализацию заглянем, то для современного ускорителя обнаружим там механику похлеще иксового протокола. В некотором роде, там тоже имеется аналог сети. Команды OGL трансформируются в драйверо-зависимый формат и в виде пакетов посылаются средствами аппаратной платформы в видеокарту. Как и в случае с сетью, приемлимую производительность мы получим только если мы хорошо нагружаем канал, и у нас нет раунд-трипов: не требуется чтение данных обратно и синхронизация с состоянием видеокарты.

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

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

Я ж там и привёл аргументы, что в вейланде сделано по-другому и никто никому ничего не должен.

Тут стоило бы уточнить, что такое «аргумент». Потому что фраза, на которую ты ответил «нет», была: «Разделение клиент-сервер должно проходить именно по линии рисующего API» в том симысле, что это наиболее эффективный способ. И наличие вейланда никак служит аргументом в пользу того, что указанный способ не самый эффективный.

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

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

Ты почему-то сосредоточился на одной задаче графического сервера — сетевой. И в упор не видишь всего остального. Поэтому единственное что я могу предложить — дождаться реализации и пощупать преимущества своими руками.

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

Во-вторых. Я сосредотачиваюсь не на поддержке сети, а на грамотной архитектуре современного графического стека, который может обеспечить гибкость и расширяемость в будущем. Разные уровни абстракции должны быть развязаны друг с другом - это аксиома. Возможность сетевого рендеринга всего лишь лакмусовая бумажка: если уж даже от того, что уже 30 лет существует, архитектура не позволяет абстрагирвоаться, то как она будет абстрагироваться от новых условий, которые возникнут в будущем? Методом порождения костылей и костылей на костылях?

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

Тогда непонятно, почему ты это отвечаешь на мою реплику «При локальной отрисовке оно должно работать быстрее, чем иксы». Причём здесь реализация ПО, если мы говорим о реализации графической подсистемы?

Я отвечаю на реплику:

Ты предлагаешь принести в жертву локальную отрисовку ради сетевой?

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

Тот же OGL является полностью network-agnostic. Когда приложение получает контекст OGL и начинает отправлять ему команды, оно понятия не имеет, что это за сущность такая и где она находится. И не имеет никакой возможности это узнать.

Всё, что происходит, когда ты в приложении вызываешь, например, glBindTexture, лежит полностью на совести реализации.

И если мы в эту реализацию заглянем, то для современного ускорителя обнаружим там механику похлеще иксового протокола. В некотором роде, там тоже имеется некий аналог сети. Команды OGL трансформируются в драйверо-зависимый формат и в виде пакетов посылаются средствами аппратной платформы в видеокарту. Как и в случае с сетью, приемлимую производительность мы получим только если мы хорошо нагружаем канал, и у нас нет раунд-трипов: не требуется чтение данных обратно и синхронизация с состоянием видеокарты.

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

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

Я ж там и привёл аргументы, что в вейланде сделано по-другому и никто никому ничего не должен.

Тут стоило бы уточнить, что такое «аргумент». Потому что фраза, на которую ты ответил «нет», была: «Разделение клиент-сервер должно проходить именно по линии рисующего API» в том симысле, что это наиболее эффективный способ. И наличие вейланда никак служит аргументом в пользу того, что указанный способ не самый эффективный.

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

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

Ты почему-то сосредоточился на одной задаче графического сервера — сетевой. И в упор не видишь всего остального. Поэтому единственное что я могу предложить — дождаться реализации и пощупать преимущества своими руками.

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

Во-вторых. Я сосредотачиваюсь не на поддержке сети, а на грамотной архитектуре современного графического стека, который может обеспечить гибкость и расширяемость в будущем. Разные уровни абстракции должны быть развязаны друг с другом - это аксиома. Возможность сетевого рендеринга всего лишь лакмусовая бумажка: если уж даже от того, что уже 30 лет существует, архитектура не позволяет абстрагирвоаться, то как она будет абстрагироваться от новых условий, которые возникнут в будущем? Методом порождения костылей и костылей на костылях?

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