Re[57]: Еще
От: c-smile Канада http://terrainformatica.com
Дата: 26.06.17 22:03
Оценка:
Здравствуйте, alex_public, Вы писали:

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


CS>>Да пофигу. Всё это вышеизложенное не зависит от кол-ва пикселей т.е. как ты и сказал — O(1).

CS>>Важно то что если оно рисует на 2000*1600 то и на 4000*3200 оно будет рисовать с тем же FPS (CPU consumption).

_>Ну так а если у тебя один алгоритм будет рисовать и UHD и FHD кадр за 50 мс (твоё любимое O(1)), а другой будет рисовать UHD за 100 мс и FHD за 25 мс (то самое ужасное O(N)), то какой ты станешь использовать? )))


DrawQuad в DirectX на 2000*1600 и 4000*3200 дисплеях рисуется за одно и то же время (если карта держит оба resolution).

Меня (на стороне CPU) не парит какой алгоритм использует та неонка GPU для того. И то и то одно и то же время и кол-во команд занимает.

_>По сути Skia+ANGLE==Direct2D. А вот кто из них эффективнее зависит от их внутренних алгоритмов использования GPU — я таких замеров не видел.


К сожалению нет. Skia изменяет состояние OpenGL (и соотв. ANGLE). Поэтому с DirectX я вот такое https://sciter.com/sciter-and-directx/
провернуть могу а с OpenGL только путем создания отдельных потоков для каждой pipeline (sciter и 3D scene).

Очень уж OpenGL древний.

CS>>DirectX работает быстрее не только из-за того что драйвера лучше но також из-за лучшей архитектуры. Stateful OpenGL это просто ужас для multithreading и pipeline интеграции.


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


Ну так уж и "ерунду".

Драйвер OpenGL на Windows 7 — ужас и тем все сказано. На Windows 10 кстати OpenGL работает на в пример лучше.

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

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

_>>>Просто не надо тащить в OpenGL подходы из 2D графики — оно всё же ориентируется в первую очередь на 3D и шейдеры, а не на рисование квадратиков на экране. Т.е. последнее тоже без проблем, но надо понимать как это сделать оптимальнее, а не в стиле рисований из GDI.

CS>>"не надо тащить" а приходится, это вот:
CS>>
CS>><div style="opacity:0.7">
CS>>   ... more stuff here ...
CS>></div>
CS>>

CS>>иначе как сначала в буфер отрисовать, а потом уже это буфер с opacity вывести не поучается. В результате и Skia и Qt вынуждены имплементировать две параллельные pipeline : и CPU и GPU имплементацию всех примитивов. Что- радости не добавляет. Т.е. и Skia и Qt могут внезапно из O(1) стать O(N) если "дезигнеру" transparency вступит в голову.

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


А давай проверим твое знание Qt

Представим что тебе нужно имплементировать метод

QWidget::setOpacity(0.0 ... 1.0)


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

CS>>К слову NanoVG это чистая GPU <canvas>/2d graphics имплементация, можно сравнить со Skia и Qt по размеру.


_>Ты немного не сравнимые библиотеки называешь. Т.е. есть смысл сравнивать NanoVG (один бэкенд) с Cairo (десятки различных бэкендов), QPaintEngine (два основных бэкенда) из Qt, Skia (два основных бэкенда). И тогда уж брать NanoGUI в роли сравниваемого с GTK, Qt и т.п. Хотя в любом случае все эти Nano проекты совсем не тянут на сравнение с подобными монстрами индустрии. )))


В Cairo backends хорошо если 10% общего кода занимают поэтому замнем сказанное выше.

А вот кстати про Cairo, GTK и Gnome...

Все эти Compiz и Metacity со товарищи они H/W accelerated. Но содержимое окна это bitmap в памяти.
Т.е. Cairo (штатный graphics в Gnome 3) нифига не accelerated — рисует также как и GDI+ и CoreGraphics — в текстуру окна.
А про OpenGL в окне Gnome лучше вообще не говорить — тоска смертная. В Sciter на Linux/GTK Skia/OpenGK тоже можно запустить. Но лучше не надо.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.