Аппаратное ускорение тулкитов

1.

Тем, что Vulkan использует то, что доступно через OpenGL ES.

2.

Но зачем, если всё прекрасно рендерится с помощью CPU?

3.

Спроси у неё.

со второй твоей темы можно ставить тебе диагноз

Давай еще третью тему накати, все так же не добавляя ни одного комментария к этим двум.

Неужто нельзя более прилично вопросы формулировать?

1. Чем хорош OpenGL ES для линукса?

Хорош тем, что не плох?

2. Что о GTK и QT?

Шлак. Если раньше еще более-менее были, то сейчас уже полный страхоужас.

Вторая должна рендериться быстрее, нужен ли ей апаратный рендеринг?

Почему это должна? Если все сделано правильно через задницу, то может быть и наоборот.

Но зачем, если всё прекрасно рендерится с помощью CPU?

1. Т.е. сейчас все тулкиты (кроме QML) рендерятся софтварно? 2. Композитный менеджер гонит всё через opengl, а значит через gpu, т.е. виджеты тулкитов обрабатываются с аппаратным ускорением?

1.

Да.

2.

С чего это вдруг?

Хорош тем, что не плох?

В квине обсуждалась его поддержка, будет ли ощутимый прирост производительности? А если бы compton его поддерживал, стал ли бы он жрать меньше ресурсов при том же результате?

Т.е. виджеты рендярятся на cpu, оттуда они композитным менеджером сразу парсятся в gpu, в итоге нет тиринга - верно?

правильно через задницу

Дожили.

Неверно. Композитинг для окон.

1. Насколько много ресурсов жрут круглые кнопки в отличие от квадратных? А если этих кнопок суммарно 50 штук в разных программах?
2. Рационально ли пользоваться в вакууме софтом, написанном на QT при использовании самой примитивной квадратной темы, а не на каком-нибудь FLTK при том же функционале и внешнем сходстве с темой кьюта? Сыграют ли в ущерб производительности скрытые возможности QT (возможость создания круглых кнопок, тени и т.п.)?

Во-первых, не путай Qt и QT — это разные вещи.

А во-вторых, не заморачивайся ты ресурсами. Ты что, для кофеварок пишешь? Пиши на том тулките на котором удобнее.

Предыдущее мое сообщение критично для меня. Вот взять gtk2 - быстрый все дела, но не на столько быстрый, как его квардратные аналоги. Там свой костыль CSS для рисования всяких округлений и прочих красявостей. Если я буду использовать квардартную хардкорную тему - он всё равно будет сделан по этой технологии CSS. Да, из-за отсутсвия округлений будет производительнее, нежели с ними, но так ли нужна эта прослойка? Вот в чем смысл 2-ого вопроса.

но не на столько быстрый, как его квардратные аналоги

Ты тесты какие-то проводил, или из головы выдумал?

Честных тестов не проводил (в плане равного функционала на разных тулкитах), но приложения из репозитория позапускал. Я конечно понимаю, что на современной технике пыль можно не экономить, но эта пыль не на столько мелка, чтобы ее игнорировать. Пишу софтину для себя, fltk полностью устраивает, но любопытство в плане гновоских лишних прослоек не дает покоя - не зря же в вяленом от лишних иксовых причуд избавлялись, так и тут. Поэтому хотелось бы получить ответ на этот комментарий.

| правильно через задницу

Суть!

Поэтому хотелось бы получить ответ на этот комментарий.

Тебя интересует детальное объяснение того как тулкиты рендерят виджеты? Или того как в WM работает композитинг? Или того как к иксам привязан OpenGL? Или полное описание графического стека линукса?

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

У тебя в голове каша из CSS, OpenGL и тулкитов.

Если я буду использовать квардартную хардкорную тему - он всё равно будет сделан по этой технологии CSS.

А это ничего, что сложность (вычислительная) применения CSS сильно зависит от сложности используемого стайлшита? Если стайлшит пустой (хардкор), он будет работать намного быстрее, чем стайлшит с кучей правил.

Да, из-за отсутсвия округлений будет производительнее, нежели с ними, но так ли нужна эта прослойка?

Прослойка мешает использовать серверный (аппаратно ускоренный) рендеринг X11. Если тебе это важно используй Motif или другой тулкит с серверным рендерингом.

В общем, учи матчасть, потом бери профайлер и вперед. (Или не бери и пользуйся тем, что тебя устраивает)

А это ничего, что сложность (вычислительная) применения CSS сильно зависит от сложности используемого стайлшита? Если стайлшит пустой (хардкор), он будет работать намного быстрее, чем стайлшит с кучей правил.

А если сравнить пустой CSS с отсутсвием написания на CSS?

Пользуясь случаем хочу спросить, а каким образом gtk и qt реализовали поддержку wayland?

будет ли ощутимый прирост производительности?

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

А если бы compton его поддерживал, стал ли бы он жрать меньше ресурсов при том же результате?

Станет ли она при этом меньше играть в Lines?