Здравствуйте, c-smile, Вы писали:

_>>Здравствуйте, c-smile, Вы писали:
CS>>>Да пофигу. Всё это вышеизложенное не зависит от кол-ва пикселей т.е. как ты и сказал — O(1).
CS>>>Важно то что если оно рисует на 2000*1600 то и на 4000*3200 оно будет рисовать с тем же FPS (CPU consumption).
_>>Ну так а если у тебя один алгоритм будет рисовать и UHD и FHD кадр за 50 мс (твоё любимое O(1)), а другой будет рисовать UHD за 100 мс и FHD за 25 мс (то самое ужасное O(N)), то какой ты станешь использовать? )))
CS>DrawQuad в DirectX на 2000*1600 и 4000*3200 дисплеях рисуется за одно и то же время (если карта держит оба resolution).
CS>Меня (на стороне CPU) не парит какой алгоритм использует та неонка GPU для того. И то и то одно и то же время и кол-во команд занимает.

И какое отношение твой ответ имеет к моему вопросу? ) Может ты всё же со мной будешь общаться, а не с мыслями в своей голове? )))

_>>По сути Skia+ANGLE==Direct2D. А вот кто из них эффективнее зависит от их внутренних алгоритмов использования GPU — я таких замеров не видел.
CS>К сожалению нет. Skia изменяет состояние OpenGL (и соотв. ANGLE). Поэтому с DirectX я вот такое https://sciter.com/sciter-and-directx/
CS>провернуть могу а с OpenGL только путем создания отдельных потоков для каждой pipeline (sciter и 3D scene).
CS>Очень уж OpenGL древний.

Не знаю как там на sciter и skia, т.к. никогда не работал с ними. Но на Qt предложенный пример делается элементарно (собственно что-то очень близкое есть даже в примерах к библиотеке) и при этом одинаково отлично работает на всех ОС. )

_>>Это ты какую-то ерунду написал. Эти два API боролись между собой уже очень давно и в разные периоды (версии) то один был лучше, то другой. Если мы возьмём последние API доступные для самой популярной десктопной ОС в данный момент (сейчас это у нас Windows7), то окажется, что OpenGL будет эффективнее (похоже что ты не посмотрел слайды, ссылку на которые я тебе кинул в предыдущем сообщение, а это был очень серьёзный материал). Если говорить о самой последней версии DirectX, то она стал заметно лучше за счёт "приближения" к железу (по типу Mantle). Но это всё уже нее имеет никакого значения, потому что вышел Вулкан, который наверняка со временем выкинет всех остальных (и OpenGL и OpenGL ES и DirectX и Mantle). Хотя бы потому, что он при такой же производительности обзавёлся поддержкой всех производителей GPU (и мобильных и десктопных) и всех ведущих OS.
CS>Ну так уж и "ерунду".
CS>Драйвер OpenGL на Windows 7 — ужас и тем все сказано. На Windows 10 кстати OpenGL работает на в пример лучше.

Драйвер OpenGL поставляется производителем чипов GPU (т.е. Nvidia, AMD, Intel) и к версии винды никакого отношения не имеет. )))

CS>Поэтому появился Vulcan который использует ту же архитектуру (по большому счету) что и DirectX.

И Vulcan и DirectX12 (только он, а не предыдущие) и Metal (из мирка Apple) все повторяют эффективные идеи Mantle (от AMD). Собственно у первопроходца был всего один, но фатальный недостаток — он работал только на картах AMD. Ну и собственно у двух остальных последователей есть аналогичные недостатки (DirectX12 — только Win10, Metal — только мирок Apple). А вот Vulkan, построенный на тех же идеях и с той же производительностью, но работает везде и со всеми. Поэтому сейчас очевидно взлетает и наверняка со временем убьёт все остальные решения.

А вот DirectX (до 12), OpenGL, OpenGL ES — это представители предыдущего идеологического поколения. И они между собой опять же имеют сравнимую производительность (хотя из последнего OpenGL возможно вытащить чуть большую, но это с применением методов изложенных в слайдах, ссылку на которые я кидал выше). Так что тут правильнее выбирать из удобства и большего охвата платформ (т.е. на мой взгляд OpenGL ES). Ну это если всё делать руками, а не пользоваться например такими https://github.com/bkaradzic/bgfx библиотечками. )))

CS>Поэтому Vulcan и DirectX 12 показывают одни и те же результаты.

Так и должно быть. )

_>>Эм, я что-то не понял, по твоему у GPU есть какие-то проблемы с отображением прозрачности или что? )
CS>А давай проверим твое знание Qt
CS>Представим что тебе нужно имплементировать метод
CS>

CS>QWidget::setOpacity(0.0 ... 1.0)
CS>

CS>Твои действия (можно словами) ?

MyWidget::setOpacity(double o) {opacity=o;}
MyWidget::paint()
{
    QPainter p;
    p.setOpacity(opacity);
    ...
}

Как-то так. )))

_>>Ты немного не сравнимые библиотеки называешь. Т.е. есть смысл сравнивать NanoVG (один бэкенд) с Cairo (десятки различных бэкендов), QPaintEngine (два основных бэкенда) из Qt, Skia (два основных бэкенда). И тогда уж брать NanoGUI в роли сравниваемого с GTK, Qt и т.п. Хотя в любом случае все эти Nano проекты совсем не тянут на сравнение с подобными монстрами индустрии. )))
CS>В Cairo backends хорошо если 10% общего кода занимают поэтому замнем сказанное выше.
CS>А вот кстати про Cairo, GTK и Gnome...
CS>Все эти Compiz и Metacity со товарищи они H/W accelerated. Но содержимое окна это bitmap в памяти.
CS>Т.е. Cairo (штатный graphics в Gnome 3) нифига не accelerated — рисует также как и GDI+ и CoreGraphics — в текстуру окна.
CS>А про OpenGL в окне Gnome лучше вообще не говорить — тоска смертная. В Sciter на Linux/GTK Skia/OpenGK тоже можно запустить. Но лучше не надо.

Насколько я помню, у Cairo имеется огромное число бэкендов, включая и OpenGL. Какой из них используется в Gnome я не в курсе. )))

Compiz и т.п. — это да, игрушки немного из другой области. Но что касается рисование в текстуру окна, то как бы и это можно делать по разному (можно через тот же GPU рисовать в видеопамять). Собственно в том же Qt это частенько используется.