Здравствуйте, 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 это частенько используется.

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

_>>>По сути 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 предложенный пример делается элементарно (собственно что-то очень близкое есть даже в примерах к библиотеке) и при этом одинаково отлично работает на всех ОС. )

Нет, не работает. Скажем у тебя есть Doom рисующий в OpenGL и ты под него хочешь подложить widget от Qt. Qt инициализирует состояние OpenGL по своему, Doom по своему.
Проблема в том что в OpenGL нет понятия context (нечто типа SkPaint или QPainter).

CS>>Драйвер OpenGL на Windows 7 — ужас и тем все сказано. На Windows 10 кстати OpenGL работает на в пример лучше.
_> Драйвер OpenGL поставляется производителем чипов GPU (т.е. Nvidia, AMD, Intel) и к версии винды никакого отношения не имеет. )))

То так. Но те драйвера "на отвяжись" ибо vendors пишут в основном для DirectX на Windows.

_>>>Эм, я что-то не понял, по твоему у 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);
_>    ...
_>}
_>

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

Ну щаз ... написано же практически русским языком:

Opacity set on the painter will apply to all drawing operations individually.

Будешь еше пытаться? Нет — давай дневник тогда.

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

Не фантазируй: X Window System (via both Xlib and XCB), Quartz, Win32, image buffers, PostScript, PDF, and SVG file output

Т.е. по одному backend на платформу + PDF и SVG. Т.е. каждая cairo dll/dylib/so содержит ровно один backend. А PDF и SVG это просто сериализаторы вызовов функций.

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

Опять мечты про шастя всем и бесплатно... Рисование в bitmap голимым CPU там ...

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

_>>Не знаю как там на sciter и skia, т.к. никогда не работал с ними. Но на Qt предложенный пример делается элементарно (собственно что-то очень близкое есть даже в примерах к библиотеке) и при этом одинаково отлично работает на всех ОС. )
CS>Нет, не работает. Скажем у тебя есть Doom рисующий в OpenGL и ты под него хочешь подложить widget от Qt. Qt инициализирует состояние OpenGL по своему, Doom по своему.
CS>Проблема в том что в OpenGL нет понятия context (нечто типа SkPaint или QPainter).

Вообще то как раз есть. Похоже ты не в курсе про существование WGL/GLX/CGL и их кроссплатформенного аналога EGL. ))) Правда тогда непонятно как ты тогда вообще пользуешься OpenGL без знания этого.

Хотя судя по предыдущему обсуждению для тебя документация и т.п. не являются доказательствами... Тогда перейдём к другой тактики дискуссии, от которой тебе уже будет трудно отмазываться. ))) Тебе кинуть ссылку на работающий пример с кучей opengl виджетов в одном окне? ) Могу даже скомпилировать его и выложить exe. )))

CS>>>Драйвер OpenGL на Windows 7 — ужас и тем все сказано. На Windows 10 кстати OpenGL работает на в пример лучше.
_>> Драйвер OpenGL поставляется производителем чипов GPU (т.е. Nvidia, AMD, Intel) и к версии винды никакого отношения не имеет. )))
CS>То так. Но те драйвера "на отвяжись" ибо vendors пишут в основном для DirectX на Windows.

Ну так тогда получается что OpenGL вообще феерически крут, т.к. если он с драйверами "на отвяжись" показывает аналогичные DirectX (<12 версии) результаты, то чтобы было с написанными со старанием драйверами...

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);
_>>    ...
_>>}
_>>

_>>Как-то так. )))
CS>Ну щаз ... написано же практически русским языком:
CS>

CS>Opacity set on the painter will apply to all drawing operations individually.

CS>Будешь еше пытаться? Нет — давай дневник тогда.

И? Что тебе не нравится то? Или опять же требуется показать работающий пример? ) С этим никаких проблем нет... )))

_>>Насколько я помню, у Cairo имеется огромное число бэкендов, включая и OpenGL. Какой из них используется в Gnome я не в курсе. )))
CS>Не фантазируй: X Window System (via both Xlib and XCB), Quartz, Win32, image buffers, PostScript, PDF, and SVG file output
CS>Т.е. по одному backend на платформу + PDF и SVG. Т.е. каждая cairo dll/dylib/so содержит ровно один backend. А PDF и SVG это просто сериализаторы вызовов функций.

Что-то у тебя похоже плохо со зрением. ) Открываем прямо на этом сайте раздел бэкендов https://cairographics.org/backends/ и видим вполне себе здоровенный список, включая вариант с OpenGL. )))

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

Ты хочешь сказать, что ты действительно не в курсе, что можно рисовать в память через GPU? )))

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

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

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

И по этой причине одна и та же видюха может плохо работать под OpenGL в одной винде, и хорошо работать под другой ? Или даже отказаться работать в более новой, потому что "гладиолус" ?
Ты не забыл, что драйвер пишется под конкретную архитектуру ?

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


CS>>Проблема в том что в OpenGL нет понятия context (нечто типа SkPaint или QPainter).

_>Вообще то как раз есть. Похоже ты не в курсе про существование WGL/GLX/CGL и их кроссплатформенного аналога EGL. ))) Правда тогда непонятно как ты тогда вообще пользуешься OpenGL без знания этого.

Все функции OpenGL работают только с current context, т.е. надо делать такое всегда:

wglMakeCurrent(...);

Т.е. ты не можешь создать два разных context на одном и том же окне. Т.е. Doom и Qt выводить на одно окно не могут — будут друг другу все регистры портить.

_>Хотя судя по предыдущему обсуждению для тебя документация и т.п. не являются доказательствами... Тогда перейдём к другой тактики дискуссии, от которой тебе уже будет трудно отмазываться. ))) Тебе кинуть ссылку на работающий пример с кучей opengl виджетов в одном окне? ) Могу даже скомпилировать его и выложить exe. )))

Разные Qt widgets — да. Разные pipelines (Doom и Qt) — нет.

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);
_>>>    ...
_>>>}
_>>>

_>>>Как-то так. )))
CS>>Ну щаз ... написано же практически русским языком:
CS>>

CS>>Opacity set on the painter will apply to all drawing operations individually.

CS>>Будешь еше пытаться? Нет — давай дневник тогда.

_>И? Что тебе не нравится то? Или опять же требуется показать работающий пример? ) С этим никаких проблем нет... )))

opacity per primitive != layer opacity.

Вот тебе пример: https://jsfiddle.net/xyc514ya/ — первый box это то что ты изобразил. Второй box — то что требуется widget.opacity = 0.7

Будешь пытаться воспроизвести? Или разойдемся на этом этапе?

Я лично знаю как это делается ибо вот оно же в Sciter:



И кстати и для Qt и кстати для Juce я backends делал — оченно хорошо в курсе того как оно там уж поверь.

_>>>Насколько я помню, у Cairo имеется огромное число бэкендов, включая и OpenGL. Какой из них используется в Gnome я не в курсе. )))
CS>>Не фантазируй: X Window System (via both Xlib and XCB), Quartz, Win32, image buffers, PostScript, PDF, and SVG file output
CS>>Т.е. по одному backend на платформу + PDF и SVG. Т.е. каждая cairo dll/dylib/so содержит ровно один backend. А PDF и SVG это просто сериализаторы вызовов функций.

_>Что-то у тебя похоже плохо со зрением. ) Открываем прямо на этом сайте раздел бэкендов https://cairographics.org/backends/ и видим вполне себе здоровенный список, включая вариант с OpenGL. )))

Я именно это и написал. Для каждой платформы там свой backend. Т.е. cairo.dll включает в себя только windows specific код. От общего размера — меньше 10%.
OpenGL experimental и не используется в production нигде. Собирать нужно отдельно. Я это делал. Ты — нет.

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

_>Ты хочешь сказать, что ты действительно не в курсе, что можно рисовать в память через GPU? )))

Ты вообще дискуссию читал ли? Мы же рисование в GPU и обсуждаем ...

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

CS>>>Проблема в том что в OpenGL нет понятия context (нечто типа SkPaint или QPainter).
_>>Вообще то как раз есть. Похоже ты не в курсе про существование WGL/GLX/CGL и их кроссплатформенного аналога EGL. ))) Правда тогда непонятно как ты тогда вообще пользуешься OpenGL без знания этого.
CS>Все функции OpenGL работают только с current context, т.е. надо делать такое всегда:
CS>

CS>wglMakeCurrent(...);
CS>

CS>Т.е. ты не можешь создать два разных context на одном и том же окне. Т.е. Doom и Qt выводить на одно окно не могут — будут друг другу все регистры портить.

Всё верно. Если тебе понадобится в приложение два отдельных OpenGL контекста (кстати, ты уже признаёшь существование такого понятия — прогресс!), то тебе понадобится для этого два отдельных окна (кстати, ты надеюсь в курсе, что они при этом могут быть даже невидимыми?). Только в чём по твоему проблема с созданием двух окон? )

_>>Хотя судя по предыдущему обсуждению для тебя документация и т.п. не являются доказательствами... Тогда перейдём к другой тактики дискуссии, от которой тебе уже будет трудно отмазываться. ))) Тебе кинуть ссылку на работающий пример с кучей opengl виджетов в одном окне? ) Могу даже скомпилировать его и выложить exe. )))
CS>Разные Qt widgets — да. Разные pipelines (Doom и Qt) — нет.

Угу, угу. Интересно только как тогда работает большая часть кода с кастомной прорисовкой на OpenGL совместно с Qt...

_>>И? Что тебе не нравится то? Или опять же требуется показать работающий пример? ) С этим никаких проблем нет... )))
CS>opacity per primitive != layer opacity.
CS>Вот тебе пример: https://jsfiddle.net/xyc514ya/ — первый box это то что ты изобразил. Второй box — то что требуется widget.opacity = 0.7

А где это у нас был разговор про layer opacity? С чего ты взял, что при реализации прозрачности у контрола надо делать не истинную прозрачность (где все его элементы начинают просвечивать), а какой-то убогий и неестественный (в реальности то такого быть не может, если конечно специально не извратиться с поляризацией света) вариант с избирательной (только относительно фона) прозрачностью?

CS>Будешь пытаться воспроизвести? Или разойдемся на этом этапе?

Вообще то в Qt такая убогая штука делается даже ещё проще:

QGraphicsOpacityEffect effect(&my_widget);
my_widget.setGraphicsEffect(&effect);
effect.setOpacity(0.5);

И да, там естественно используется рисование в память. Но при этом мы уже обсуждали, что никто не мешает рисовать в память с помощью GPU.

_>>>>Насколько я помню, у Cairo имеется огромное число бэкендов, включая и OpenGL. Какой из них используется в Gnome я не в курсе. )))
CS>>>Не фантазируй: X Window System (via both Xlib and XCB), Quartz, Win32, image buffers, PostScript, PDF, and SVG file output
CS>>>Т.е. по одному backend на платформу + PDF и SVG. Т.е. каждая cairo dll/dylib/so содержит ровно один backend. А PDF и SVG это просто сериализаторы вызовов функций.
_>>Что-то у тебя похоже плохо со зрением. ) Открываем прямо на этом сайте раздел бэкендов https://cairographics.org/backends/ и видим вполне себе здоровенный список, включая вариант с OpenGL. )))
CS>Я именно это и написал. Для каждой платформы там свой backend. Т.е. cairo.dll включает в себя только windows specific код. От общего размера — меньше 10%.
CS>OpenGL experimental и не используется в production нигде. Собирать нужно отдельно. Я это делал. Ты — нет.

Так получается OpenGL бэкенд у Cairo не существует (как утверждал ты) или же нигде не используется (я кстати и не утверждал, что он где-то используется, хотя опять же возможно и это твоё утверждение не верно — надо проверять)? )))

_>>Ты хочешь сказать, что ты действительно не в курсе, что можно рисовать в память через GPU? )))
CS>Ты вообще дискуссию читал ли? Мы же рисование в GPU и обсуждаем ...

Правильно. И я тебе говорю, что из того факта, что некая система оперирует окнами как готовыми картинками (текстурами) совершенно не следует, что эти картинки не были перед этим так же отрисованы с помощью GPU (рисование могло происходить в память, а не на экран).

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

CS>>Будешь пытаться воспроизвести? Или разойдемся на этом этапе?

_>Вообще то в Qt такая убогая штука делается даже ещё проще:
_>

_>QGraphicsOpacityEffect effect(&my_widget);
_>my_widget.setGraphicsEffect(&effect);
_>effect.setOpacity(0.5);
_>

_>И да, там естественно используется рисование в память. Но при этом мы уже обсуждали, что никто не мешает рисовать в память с помощью GPU.

Ну а я про что тебе говорил? Про то что Qt рисует в память и что в уж слишком многих случаях там рисование O(dpi) complex.

Что и подтверждается этим вот:

Note: Graphics effects are not supported for OpenGL-based widgets, such as QGLWidget, QOpenGLWidget and QQuickWidget.

Всё на этом обсуждение заканчиваю ибо ничего интересного/нового увы не ожидаю.

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

_>>Вообще то в Qt такая убогая штука делается даже ещё проще:
_>>

_>>QGraphicsOpacityEffect effect(&my_widget);
_>>my_widget.setGraphicsEffect(&effect);
_>>effect.setOpacity(0.5);
_>>

_>>И да, там естественно используется рисование в память. Но при этом мы уже обсуждали, что никто не мешает рисовать в память с помощью GPU.
CS>Ну а я про что тебе говорил? Про то что Qt рисует в память и что в уж слишком многих случаях там рисование O(dpi) complex.

За всё время использования библиотеки Qt мне пришлось использовать подобный режим прозрачности приблизительно никогда. Так что использование данного случая в качестве доказательства выглядит очень забавно. )))

CS>Что и подтверждается этим вот:
CS>

CS>Note: Graphics effects are not supported for OpenGL-based widgets, such as QGLWidget, QOpenGLWidget and QQuickWidget.

Да, всё верно. Потому что функция sourcePixmap из эффектов работает через Painter. Однако её можно элементарно расширить и на работу с OpenGL окнами, реализовав создание Pixmap из FBO. Только вот никто этим не занимается, потому что это всё банально не нужно при наличие в системе нормальной взрослой прозрачности и вообще работы на уровне шейдеров. ))) Это как раз то, о чём я и говорил насчёт глупости использования GDI замашек на современных GPU.

CS>Всё на этом обсуждение заканчиваю ибо ничего интересного/нового увы не ожидаю.

Ну ну, не надо лукавить. Если посмотреть всё обсуждение, то легко увидеть, что ты узнал тут много нового про работу OpenGL, DirectX и т.п. ) Что кстати довольно странно, т.к. по идее это относится к твоей области специализации и ты должен был знать это всё сам.

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

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


В недрах bgfx сидит такое:

static int32_t renderThread(void* /*_userData*/)
{
...
   while (RenderFrame::Exiting != bgfx::renderFrame()) {  };
...                        
   return bx::kExitSuccess;
}

У меня один процессор из двух сразу загружается на 100%. Аналогичные по сложности демо-программы из SDK DirectX грузят процессор на пару процентов.
Примерчик из Sciter-a (DirectX) с вращающимся кубиком ведет себя таким же недопустимым образом.
API bgfx не самый дружественный, но Бранимир Караджич всё равно молоток.

PS
С ANGLE никогда не работал, только в руках вертел, но API в духе OpenGL больше располагает к работе чем стиль bgfx

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

P>В недрах bgfx сидит такое:
P>

P>static int32_t renderThread(void* /*_userData*/)
P>{
P>...
P>   while (RenderFrame::Exiting != bgfx::renderFrame()) {  };
P>...                        
P>   return bx::kExitSuccess;
P>}
P>

P>У меня один процессор из двух сразу загружается на 100%. Аналогичные по сложности демо-программы из SDK DirectX грузят процессор на пару процентов.
P>Примерчик из Sciter-a (DirectX) с вращающимся кубиком ведет себя таким же недопустимым образом.
P>API bgfx не самый дружественный, но Бранимир Караджич всё равно молоток.

Ужасы какие. Хотя возможно для игр это и приемлемо, не знаю. Но для GUI и т.п. выглядит сомнительно. )

P>PS
P>С ANGLE никогда не работал, только в руках вертел, но API в духе OpenGL больше располагает к работе чем стиль bgfx

Да, я сам тоже предпочитаю использовать везде один интерфейс (OpenGL) и напрямую (без библиотек-обёрток). Кстати, хорошо что именно OpenGL ES приняли за стандарт для доступа к GPU в браузере.

Хотя возможно через какое-то время придётся переучиваться на Vulkan, но пока это актуально только для самых нагруженных приложений.

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

P>Здравствуйте, alex_public, Вы писали:

P>В недрах bgfx сидит такое:
P>

P>static int32_t renderThread(void* /*_userData*/)
P>{
P>...
P>   while (RenderFrame::Exiting != bgfx::renderFrame()) {  };
P>...                        
P>   return bx::kExitSuccess;
P>}
P>

P>У меня один процессор из двух сразу загружается на 100%. Аналогичные по сложности демо-программы из SDK DirectX грузят процессор на пару процентов.
P>Примерчик из Sciter-a (DirectX) с вращающимся кубиком ведет себя таким же недопустимым образом.
P>API bgfx не самый дружественный, но Бранимир Караджич всё равно молоток.

Тот пример из Sciter SDK это практически оригинальный пример из DirectX SDK. А там они крутят такой вот "pure man's animation loop":

    MSG msg = {0};
    while( WM_QUIT != msg.message )
    {
        if( PeekMessage( &msg, NULL, 0, 0, PM_REMOVE ) )
        {
            TranslateMessage( &msg );
            DispatchMessage( &msg );
        }
        else
        {
            Render();
        }
    }

Т.е. Render() всего и вся зовется в loop невзирая на то изменилось ли что-то или нет. В реалии это делается не так.

Просто добавить там

        else
        {
            Render();
            Sleep(10);  
        }

Т.е. 100 FPS max cap и уже картинка меняется:

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

CS>Просто добавить там
CS>

CS>        else
CS>        {
CS>            Render();
CS>            Sleep(10);  
CS>        }
CS>

Непонятно. Если это user input тред, то непонятно, откуда сообщения от юзера будут щимиться — поток то спит, то рисует. Можно забрасывать сообщения через таймер и проверять именно их.

В gdi+ Режиме у скитера такой же луп ? Если такой же и рисование в том же треде, т.е. ui, то это объясняет, почему скитер слабо юзает процессор, хотя в gdi+ он должен забирать всё ядро.

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

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

CS>>Просто добавить там
CS>>

CS>>        else
CS>>        {
CS>>            Render();
CS>>            Sleep(10);  
CS>>        }
CS>>

I>Непонятно. Если это user input тред, то непонятно, откуда сообщения от юзера будут щимиться — поток то спит, то рисует. Можно забрасывать сообщения через таймер и проверять именно их.

Render() в данном конкретном примере работает меньше 1ms. Т.е. Sleep(10); здесь просто гарантирует что Render вызывается не чаше чем 10ms т.е. max FPS = 100.

I>В gdi+ Режиме у скитера такой же луп ? Если такой же и рисование в том же треде, т.е. ui, то это объясняет, почему скитер слабо юзает процессор, хотя в gdi+ он должен забирать всё ядро.

Sciter не содержит message pump loop. Это дело host application.

Просто когда в Sciter что-то изменилось то я зову ::InvalidateRect(). В ответ Windows делает (условно) ::PostMessage(hwnd,WM_PAINT,...);

Частота прихода WM_PAINT есть 60 FPS по умолчанию. Но эта частота зависит от нагрузки.
Если обработка WM_PAINT занимает значительное время, то WM_PAINT начинает приходить реже (что естественно).

Т.е. в GDI+ frame rendering загружает СPU сильно, что вызывает WM_PAINT приходить через раз (условно) и FPS становится ниже.
Тулзы типа ProcessExplorer показывают интегральную загрузку CPU. Т.е. в среднее значение за последнюю секунду или типа того.

И вообще про GetMessage/PeekMessage : https://blogs.msdn.microsoft.com/oldnewthing/20111219-00/?p=8863

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

CS>Т.е. в GDI+ frame rendering загружает СPU сильно, что вызывает WM_PAINT приходить через раз (условно) и FPS становится ниже.
CS>Тулзы типа ProcessExplorer показывают интегральную загрузку CPU. Т.е. в среднее значение за последнюю секунду или типа того.

У меня сколько я ни гонял скитер, больше 13% ни разу не было, обычно 12...12.9. Т.е. загружено ровно пол-ядра. Было предположение, что это особенность эвентлупа а не собственно рендеринга. Если это не эвентлуп, то очень странно видеть загрузку половины ядра в gdi+ режиме. Должно быть какое то другое рациональное объяснение.

Мб это сделано специально, для энергосбережения или еще чего. Просто когда я делал гладкую прокрутку через gdi+, у меня примерно на 50-60 фпс загрузка CPU была около 80...90% ядра, т.е. в пересчете на 4 ядра это около 20-22%. Фрейм рисовался обычно 20-30мс.

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

V>Плохо ты помнишь тулбары из 90-х, судя по всему.

У штатных виндовых тулбаров из commctl кнопки окнами не были с самого начала.

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

CC>
CC>В плане гуя что сервер что нет — один и тот же код.

Как минимум драйвера штатно там разные. В серверных упор сделан на стабильность в ущерб скорости.

Здравствуйте, Mystic Artifact, Вы писали:

MA>Как и нет второстепенных ручек, навроде политики роста кучи и т.п.

Кое что есть, через интерфейсы хоста. А рантайм Core так вообще в исходниках доступен и открыт для предложения патчей.

MA> — возможность эффективно/удобно выделять объекты на стэке, а не только в куче.

Рантайм .NET это умеет, не умеет C# (точнее даже немножко умеет).

MA> — возможность нормально интегрироваться с C кодом. (PInvoke — это ненормально

Чем ненормально?

MA> — возможность нормально интегрироваться с C++ кодом, в API которого учавствуют хотя бы не сложные шаблоны (т.е. без магии, но всё же шаблоны).

С++/CLI?

MA> — опять возвращаясь к GC: возможность применять GC только к интересующим объектам, и "не платить" за него, когда он не нужен. Даже если этих мест где GC строго противопоказан ограниченное количество — с этим прийдётся что-то делать.

Руками работать с массивами? Муторно, но лучше чем ничего. Если объектов мало — вполне оправдано.

MA> В рантайме безусловно должен быть приличный JIT или возможность AOT (с хорошим качеством). .NET тут традиционно пролетает от слова совсем.

Что не так с RjuJIT? И чем .NET Native не AOT?

MA>Серьёзно же пилить движок, который будет "сливать" конкуретнам — думаю смысла нет

Сейчас вообще нет особого смысла пилить движок, даже не уступающий конкурентам.

MA>Да самый примитивный рендерер на .NET (безусловно с неравными общими характеристиками) будет в разы лучше, чем это.

С OAuth не все так просто. В 2.0, правда, есть определенные подвижки.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Как минимум драйвера штатно там разные. В серверных упор сделан на стабильность в ущерб скорости.
Ага, nVidia делает отдельный драйвер для сервера для игровых карт?
Или сетевые драйвера на сервере спецом медленнее работают?
Сам то понял что сказал?

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

НС>>Как минимум драйвера штатно там разные. В серверных упор сделан на стабильность в ущерб скорости.
CC>Ага, nVidia делает отдельный драйвер для сервера для игровых карт?

МС поставляет в комплекте свою версию. А те что с сайта нвидии не факт что на сервер встанут.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>А те что с сайта нвидии не факт что на сервер встанут.
Ты поди забыл что я на серверных версиях с W2K живу.
Всё там прекрасно встаёт и работает.