Сообщение Re[56]: Еще от 26.06.2017 19:25
Изменено 26.06.2017 19:41 alex_public
Re[56]: Еще
Здравствуйте, 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>ANGLE существует потому как OpenGL (а особенно OpenGL ES) это subset DirectX функциональности. В любом случае это доп. layer который скорости не прибавляет.
Конечно же не прибавляет, но и особо не убавляет, т.к. это у нас C++ и все функции в стиле обёрток (а таких там большинство) просто исчезают после прохода оптимизатора. Собственно из реально алгоритмических кусков там наверное только транслятор из одного языка шейдеров в другой, но он обычно отрабатывает на этапе инициализации приложения.
По сути Skia+ANGLE==Direct2D. А вот кто из них эффективнее зависит от их внутренних алгоритмов использования GPU — я таких замеров не видел.
CS>DirectX работает быстрее не только из-за того что драйвера лучше но також из-за лучшей архитектуры. Stateful OpenGL это просто ужас для multithreading и pipeline интеграции.
Это ты какую-то ерунду написал. Эти два API боролись между собой уже очень давно и в разные периоды (версии) то один был лучше, то другой. Если мы возьмём последние API доступные для самой популярной десктопной ОС в данный момент (сейчас это у нас Windows7), то окажется, что OpenGL будет эффективнее (похоже что ты не посмотрел слайды, ссылку на которые я тебе кинул в предыдущем сообщение, а это был очень серьёзный материал). Если говорить о самой последней версии DirectX, то она стал заметно лучше за счёт "приближения" к железу (по типу Mantle). Но это всё уже нее имеет никакого значения, потому что вышел Вулкан, который наверняка со временем выкинет всех остальных (и OpenGL и OpenGL ES и DirectX и Mantle). Хотя бы потому, что он при такой же производительности обзавёлся поддержкой всех производителей GPU (и мобильных и десктопных) и всех ведущих OS.
_>>Просто не надо тащить в OpenGL подходы из 2D графики — оно всё же ориентируется в первую очередь на 3D и шейдеры, а не на рисование квадратиков на экране. Т.е. последнее тоже без проблем, но надо понимать как это сделать оптимальнее, а не в стиле рисований из GDI.
CS>"не надо тащить" а приходится, это вот:
CS>
CS>иначе как сначала в буфер отрисовать, а потом уже это буфер с opacity вывести не поучается. В результате и Skia и Qt вынуждены имплементировать две параллельные pipeline : и CPU и GPU имплементацию всех примитивов. Что- радости не добавляет. Т.е. и Skia и Qt могут внезапно из O(1) стать O(N) если "дезигнеру" transparency вступит в голову.
Эм, я что-то не понял, по твоему у GPU есть какие-то проблемы с отображением прозрачности или что? )
Кстати у меня прямо сейчас перед руками проектик на Qt, в котором множество различных контролов (у которых нет собственного фона) рисуются поверх реалтаймого FHD видео. И не наблюдается ни малейших проблем даже на самых убогих процессорах и gpu (в не топовых момобильниках). А на десктопе вообще загрузка CPU в пару процентов. )))
CS>К слову NanoVG это чистая GPU <canvas>/2d graphics имплементация, можно сравнить со Skia и Qt по размеру.
Ты немного не сравнимые библиотеки называешь. Т.е. есть смысл сравнивать NanoVG (один бэкенд) с Cairo (десятки различных бэкендов), QPaintEngine (два основных бэкенда) из Qt, Skia (два основных бэкенда). И тогда уж брать NanoGUI в роли сравниваемого с GTK, Qt и т.п. Хотя в любом случае все эти Nano проекты совсем не тянут на сравнение с подобными монстрами индустрии. )))
Так вот, каких то сравнений по производительности Skia или NanoVG я не видел. А вот сравнение 2D бэкенда Qt с Cairo и Direct2D я в прошлые годы видел не мало. И помнится по тем тестам OpenGL рендерер Qt обходил Direct2D в разы, а Cairo на порядок. )))
CS>Да пофигу. Всё это вышеизложенное не зависит от кол-ва пикселей т.е. как ты и сказал — O(1).
CS>Важно то что если оно рисует на 2000*1600 то и на 4000*3200 оно будет рисовать с тем же FPS (CPU consumption).
Ну так а если у тебя один алгоритм будет рисовать и UHD и FHD кадр за 50 мс (твоё любимое O(1)), а другой будет рисовать UHD за 100 мс и FHD за 25 мс (то самое ужасное O(N)), то какой ты станешь использовать? )))
CS>ANGLE существует потому как OpenGL (а особенно OpenGL ES) это subset DirectX функциональности. В любом случае это доп. layer который скорости не прибавляет.
Конечно же не прибавляет, но и особо не убавляет, т.к. это у нас C++ и все функции в стиле обёрток (а таких там большинство) просто исчезают после прохода оптимизатора. Собственно из реально алгоритмических кусков там наверное только транслятор из одного языка шейдеров в другой, но он обычно отрабатывает на этапе инициализации приложения.
По сути Skia+ANGLE==Direct2D. А вот кто из них эффективнее зависит от их внутренних алгоритмов использования GPU — я таких замеров не видел.
CS>DirectX работает быстрее не только из-за того что драйвера лучше но також из-за лучшей архитектуры. Stateful OpenGL это просто ужас для multithreading и pipeline интеграции.
Это ты какую-то ерунду написал. Эти два API боролись между собой уже очень давно и в разные периоды (версии) то один был лучше, то другой. Если мы возьмём последние API доступные для самой популярной десктопной ОС в данный момент (сейчас это у нас Windows7), то окажется, что OpenGL будет эффективнее (похоже что ты не посмотрел слайды, ссылку на которые я тебе кинул в предыдущем сообщение, а это был очень серьёзный материал). Если говорить о самой последней версии DirectX, то она стал заметно лучше за счёт "приближения" к железу (по типу Mantle). Но это всё уже нее имеет никакого значения, потому что вышел Вулкан, который наверняка со временем выкинет всех остальных (и OpenGL и OpenGL ES и DirectX и Mantle). Хотя бы потому, что он при такой же производительности обзавёлся поддержкой всех производителей GPU (и мобильных и десктопных) и всех ведущих OS.
_>>Просто не надо тащить в 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, в котором множество различных контролов (у которых нет собственного фона) рисуются поверх реалтаймого FHD видео. И не наблюдается ни малейших проблем даже на самых убогих процессорах и gpu (в не топовых момобильниках). А на десктопе вообще загрузка CPU в пару процентов. )))
CS>К слову NanoVG это чистая GPU <canvas>/2d graphics имплементация, можно сравнить со Skia и Qt по размеру.
Ты немного не сравнимые библиотеки называешь. Т.е. есть смысл сравнивать NanoVG (один бэкенд) с Cairo (десятки различных бэкендов), QPaintEngine (два основных бэкенда) из Qt, Skia (два основных бэкенда). И тогда уж брать NanoGUI в роли сравниваемого с GTK, Qt и т.п. Хотя в любом случае все эти Nano проекты совсем не тянут на сравнение с подобными монстрами индустрии. )))
Так вот, каких то сравнений по производительности Skia или NanoVG я не видел. А вот сравнение 2D бэкенда Qt с Cairo и Direct2D я в прошлые годы видел не мало. И помнится по тем тестам OpenGL рендерер Qt обходил Direct2D в разы, а Cairo на порядок. )))
Re[56]: Еще
Здравствуйте, 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>ANGLE существует потому как OpenGL (а особенно OpenGL ES) это subset DirectX функциональности. В любом случае это доп. layer который скорости не прибавляет.
Конечно же не прибавляет, но и особо не убавляет, т.к. это у нас C++ и все функции в стиле обёрток (а таких там большинство) просто исчезают после прохода оптимизатора. Собственно из реально алгоритмических кусков там наверное только транслятор из одного языка шейдеров в другой, но он обычно отрабатывает на этапе инициализации приложения.
По сути Skia+ANGLE==Direct2D. А вот кто из них эффективнее зависит от их внутренних алгоритмов использования GPU — я таких замеров не видел.
CS>DirectX работает быстрее не только из-за того что драйвера лучше но також из-за лучшей архитектуры. Stateful OpenGL это просто ужас для multithreading и pipeline интеграции.
Это ты какую-то ерунду написал. Эти два API боролись между собой уже очень давно и в разные периоды (версии) то один был лучше, то другой. Если мы возьмём последние API доступные для самой популярной десктопной ОС в данный момент (сейчас это у нас Windows7), то окажется, что OpenGL будет эффективнее (похоже что ты не посмотрел слайды, ссылку на которые я тебе кинул в предыдущем сообщение, а это был очень серьёзный материал). Если говорить о самой последней версии DirectX, то она стал заметно лучше за счёт "приближения" к железу (по типу Mantle). Но это всё уже нее имеет никакого значения, потому что вышел Вулкан, который наверняка со временем выкинет всех остальных (и OpenGL и OpenGL ES и DirectX и Mantle). Хотя бы потому, что он при такой же производительности обзавёлся поддержкой всех производителей GPU (и мобильных и десктопных) и всех ведущих OS.
_>>Просто не надо тащить в OpenGL подходы из 2D графики — оно всё же ориентируется в первую очередь на 3D и шейдеры, а не на рисование квадратиков на экране. Т.е. последнее тоже без проблем, но надо понимать как это сделать оптимальнее, а не в стиле рисований из GDI.
CS>"не надо тащить" а приходится, это вот:
CS>
CS>иначе как сначала в буфер отрисовать, а потом уже это буфер с opacity вывести не поучается. В результате и Skia и Qt вынуждены имплементировать две параллельные pipeline : и CPU и GPU имплементацию всех примитивов. Что- радости не добавляет. Т.е. и Skia и Qt могут внезапно из O(1) стать O(N) если "дезигнеру" transparency вступит в голову.
Эм, я что-то не понял, по твоему у GPU есть какие-то проблемы с отображением прозрачности или что? )
Кстати у меня прямо сейчас перед руками проектик на Qt, в котором множество различных контролов (у которых нет собственного фона) рисуются поверх реалтаймого FHD видео. И не наблюдается ни малейших проблем даже на самых убогих процессорах и gpu (в не топовых момобильниках). А на десктопе вообще загрузка CPU в пару процентов. )))
CS>К слову NanoVG это чистая GPU <canvas>/2d graphics имплементация, можно сравнить со Skia и Qt по размеру.
Ты немного не сравнимые библиотеки называешь. Т.е. есть смысл сравнивать NanoVG (один бэкенд) с Cairo (десятки различных бэкендов), QPaintEngine (два основных бэкенда) из Qt, Skia (два основных бэкенда). И тогда уж брать NanoGUI в роли сравниваемого с GTK, Qt и т.п. Хотя в любом случае все эти Nano проекты совсем не тянут на сравнение с подобными монстрами индустрии. )))
Так вот, каких то сравнений по производительности Skia или NanoVG я не видел. А вот сравнений 2D бэкенда Qt с Cairo, GDI и графикой WPF я в прошлые годы видел не мало. И помнится по тем тестам OpenGL рендерер Qt обходил GDI и WPF в разы, а Cairo на порядок. )))
CS>Да пофигу. Всё это вышеизложенное не зависит от кол-ва пикселей т.е. как ты и сказал — O(1).
CS>Важно то что если оно рисует на 2000*1600 то и на 4000*3200 оно будет рисовать с тем же FPS (CPU consumption).
Ну так а если у тебя один алгоритм будет рисовать и UHD и FHD кадр за 50 мс (твоё любимое O(1)), а другой будет рисовать UHD за 100 мс и FHD за 25 мс (то самое ужасное O(N)), то какой ты станешь использовать? )))
CS>ANGLE существует потому как OpenGL (а особенно OpenGL ES) это subset DirectX функциональности. В любом случае это доп. layer который скорости не прибавляет.
Конечно же не прибавляет, но и особо не убавляет, т.к. это у нас C++ и все функции в стиле обёрток (а таких там большинство) просто исчезают после прохода оптимизатора. Собственно из реально алгоритмических кусков там наверное только транслятор из одного языка шейдеров в другой, но он обычно отрабатывает на этапе инициализации приложения.
По сути Skia+ANGLE==Direct2D. А вот кто из них эффективнее зависит от их внутренних алгоритмов использования GPU — я таких замеров не видел.
CS>DirectX работает быстрее не только из-за того что драйвера лучше но також из-за лучшей архитектуры. Stateful OpenGL это просто ужас для multithreading и pipeline интеграции.
Это ты какую-то ерунду написал. Эти два API боролись между собой уже очень давно и в разные периоды (версии) то один был лучше, то другой. Если мы возьмём последние API доступные для самой популярной десктопной ОС в данный момент (сейчас это у нас Windows7), то окажется, что OpenGL будет эффективнее (похоже что ты не посмотрел слайды, ссылку на которые я тебе кинул в предыдущем сообщение, а это был очень серьёзный материал). Если говорить о самой последней версии DirectX, то она стал заметно лучше за счёт "приближения" к железу (по типу Mantle). Но это всё уже нее имеет никакого значения, потому что вышел Вулкан, который наверняка со временем выкинет всех остальных (и OpenGL и OpenGL ES и DirectX и Mantle). Хотя бы потому, что он при такой же производительности обзавёлся поддержкой всех производителей GPU (и мобильных и десктопных) и всех ведущих OS.
_>>Просто не надо тащить в 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, в котором множество различных контролов (у которых нет собственного фона) рисуются поверх реалтаймого FHD видео. И не наблюдается ни малейших проблем даже на самых убогих процессорах и gpu (в не топовых момобильниках). А на десктопе вообще загрузка CPU в пару процентов. )))
CS>К слову NanoVG это чистая GPU <canvas>/2d graphics имплементация, можно сравнить со Skia и Qt по размеру.
Ты немного не сравнимые библиотеки называешь. Т.е. есть смысл сравнивать NanoVG (один бэкенд) с Cairo (десятки различных бэкендов), QPaintEngine (два основных бэкенда) из Qt, Skia (два основных бэкенда). И тогда уж брать NanoGUI в роли сравниваемого с GTK, Qt и т.п. Хотя в любом случае все эти Nano проекты совсем не тянут на сравнение с подобными монстрами индустрии. )))
Так вот, каких то сравнений по производительности Skia или NanoVG я не видел. А вот сравнений 2D бэкенда Qt с Cairo, GDI и графикой WPF я в прошлые годы видел не мало. И помнится по тем тестам OpenGL рендерер Qt обходил GDI и WPF в разы, а Cairo на порядок. )))