Так я про это и говорю, порезать кодеки в ffmpeg довольно легко
Оптимизация за 5 минут, но почему-то даже для мобильных приложений, постоянно встречаю в apk в jniLibs/armeabi-v7a/ полностью собранные _все_ библиотеки от ffmpeg (когда используется только h264). Хотя казалось бы трафик пользователя надо экономить.
Когда обычно просто подключают ffmpeg или gstreamer. Причем это будет или зависимость, если это софт из репы линукса (это еще может быть оправдано ради качества/скорости кодирования), или просто скомпиленная дефолтная версия для винды\андройда\мака, чтобы неиспользуемые кодеки порезали и сократили размер до ~мегабайта — не видел такого.
А чем не устраивают готовые nuklear, ImGUI?
Есть еще основы типа github.com/randrew/layout
Можно очень красивые интерфейсы сделать на этих штуках. А всякие красивости на шейдерах.
wxWidgets можно сразу выкинуть, на маке отрисовка текста через CTLineDraw и тормозит.
QT можно, если размер не важен, но если сами будите пересобирать — можно больше времени потратить.
А не знаете еще симулятора (кроме платных армовых тулзов), который может количество клоктиков просимулировать и профайл показать. На худой конец инструкции но без танцев с бубном, для QEMU я костыль сделал github.com/lieff/qemu-prof. Не знаю есть ли способ проще.
Для упрощения еще можно воспользоваться семихостингом. Для arm-none-eabi-gcc это будет что-то типа
arm-none-eabi-gcc -mthumb -mlittle-endian -march=armv7-m -mcpu=cortex-m3 test.c -o test --specs=rdimon.specs
Заработает стандартный printf и file IO, которые будут транслироваться на хост.
Для linaro тулзов arm-linux-gnueabi-gcc/arm-linux-gnueabihf-gcc еще проще:
arm-linux-gnueabi-gcc -static -mthumb -mlittle-endian -march=armv7-m -mcpu=cortex-m3 test.c -o test
В обоих случаях получаем бинарь, который можно запустить на QEMU и ввод-вывод будет редиректиться на хост.
В убунте эти тулзы можно установить из репозитария, а полученный бинарь автоматом будет запускаться через QEMU — очень удобно.
Hairworks это только одна из проблем SO в W3 github.com/doitsujin/dxvk/issues/138
Еще некоторые враги невидимы и другие мелкие артефакты вроде отрисовки волос и бороды. На полноценную поддержку все еще не тянет. Хорошо что не так многим играм нужен SO, работает очень многое без всяких настроек и с хорошей скоростью. В некоторых играх даже плюсы есть, например в DA Origins у меня куда быстрее загрузки в лине нежели в винде. И это тулза только вышла и в бэте.
Witcher 3 — это вы погорячились, игра требует Stream Output, который пока dxvk не поддерживает. Потому для нормальной скорости пока он не работает как должно (хотя и можно пройти). В остальном да, я опробовал с десяток интересующих меня win-only игр из своей библиотеки, и все они заработали без каких либо проблем.
> никаких GC быть не должно и кадры должны выводиться с одной частотой (если они готовы).
Проблема в том, что по факту это не так. Это может быть не GC, а что угодно, просто наблюдаемый факт, что драйвер чем-то занимается после реального обновления. У меня это проявляется и на Linux и на Windows. Драйверам никто не запрещает это делать, по документации все четко, ничего не нарушается. Да и от GC никуда не деться, если не на swap его выполнять (когда как раз кадр завершили и логично почистить), на идущий следом glClear()? В общем кривота это все, знать реальное время отображения нужно, без этого никуда.
На шейдертое симуляция вообще высчитывается из всего диапазона float iGlobalTime, это эквивалентно 1/FLOAT_MIN рассчетов/сек, без учета ошибок округления. Это не помогает, проблема вот в чем:
Это лучше чем glFinish, если движок умеет ставить команды на поток. glFinish ждет сразу и нет возможности накидать команд дальше. А так: ставим точки синхронизации и кидаем команд сколько возможно, пока нет зависимостей с тем что уже считается, ждем на них, накидываем еще команд (при этом пока ждали уже все подготовили), когда знаем что точка прошла и теперь безопасно что-то трогать. При этом стараемся чтобы GPU был всегда нагружен. Однако в данной проблеме это ничем не поможет — нет такой точки «сейчас экран обновился», есть только «swap закончился».
Основной посыл в том, что конец swap нельзя считать за время отображения. Реально отображение произошло через 16мс, а драйвер висел еще 8мс (а может и не висеть, как ему захочется). Когда драйвер себе такое позволяет (а кто ему запрещал? в доке про swap ни слова когда именно будет отображение), ничего без костылей, которые будут работать в данном конкретном случае, но не заработают в другом, сделать уже ничего нельзя. Нужно вносить в документацию понятие времени отображения, что гугл и сделал.
Я потому про него и написал, glFinish + swap получаем теоретическую неопределенность только 0-16мс с синком. Но принципиальным это не является, мы ведь считаем за время отображения конец swap. Если он таковым не является по неизвестной нам причине, вот возникло у драйвера еще работы на 5мс после свопа из-за архитекрутных/драйверных особенностей, то привет. Хорошо если оно постоянное, а если переменное (например переодическое GC запустили) — беда. Вот в статье как раз описано: выброс до 24.8мс на самом деле фейковый, если его принять за 16.6 — то все плавно, то-есть время отображения было 16.6, а 8.2мс драйвер занимался неизвестно чем. Плюс стратегий компенсации может быть множество, если мы хотим что-то предсказать и компенсировать, указать желаемое время отображения опять же без расширения способа нету.
А чем это поможет? Представьте что у вас swapBuffers только из-за синхронизации выполняется от 0мс до 16мс (заранее неизвестно сколько, этого вполне достаточно для stutter) + работает еще неизвестно сколько, если перед этим не было glFinish + общая нагрузка меняется немного от кадра к кадру + вы не знаете когда реально при работе swapBuffers произошло отображение. Это может уменьшить эффект, но реальную проблему этим не решить. Надо знать когда именно было отображение в swapBuffers + надо иметь возможность сообщить лучшее время отображения следующего кадра (мы же исходя из всех расчетов передвинули куда-то геометрию, где предполагаем след кадр будет отображен, но драйвер об этом ничего не знает), вот теперь это можно сделать используя VkPresentTimesInfoGOOGLE.
Есть пример github.com/KhronosGroup/Vulkan-Tools/blob/master/cube/cube.c
Проблема в том что swapBuffers может висеть довольно долго и реальное отображение будет неизвестно когда в этом промежутке, это не обязательно конец swap+glFinish и подобному. Вот это расширение позволяет узнать когда же оно реально было. В будущее никто не заглядывает, просто учитываешь это при генерации следующего кадра. Тут конечно еще может быть время пока кадр дойдет до монитора, но оно обычно уже постоянное и на «stutter» уже не влияет.
Имеется ввиду www.openfl.org который использует haxe.org?
В openfl из haxe программы используешь swf ассеты, которая потом транслируется в другие языки. Это не совсем флеш и поддержка swf там далеко не полная.
Оптимизация за 5 минут, но почему-то даже для мобильных приложений, постоянно встречаю в apk в jniLibs/armeabi-v7a/ полностью собранные _все_ библиотеки от ffmpeg (когда используется только h264). Хотя казалось бы трафик пользователя надо экономить.
github.com/lieff/minih264
github.com/lieff/minirtmp
Когда обычно просто подключают ffmpeg или gstreamer. Причем это будет или зависимость, если это софт из репы линукса (это еще может быть оправдано ради качества/скорости кодирования), или просто скомпиленная дефолтная версия для винды\андройда\мака, чтобы неиспользуемые кодеки порезали и сократили размер до ~мегабайта — не видел такого.
Есть еще основы типа github.com/randrew/layout
Можно очень красивые интерфейсы сделать на этих штуках. А всякие красивости на шейдерах.
wxWidgets можно сразу выкинуть, на маке отрисовка текста через CTLineDraw и тормозит.
QT можно, если размер не важен, но если сами будите пересобирать — можно больше времени потратить.
arm-none-eabi-gcc -mthumb -mlittle-endian -march=armv7-m -mcpu=cortex-m3 test.c -o test --specs=rdimon.specs
Заработает стандартный printf и file IO, которые будут транслироваться на хост.
Для linaro тулзов arm-linux-gnueabi-gcc/arm-linux-gnueabihf-gcc еще проще:
arm-linux-gnueabi-gcc -static -mthumb -mlittle-endian -march=armv7-m -mcpu=cortex-m3 test.c -o test
В обоих случаях получаем бинарь, который можно запустить на QEMU и ввод-вывод будет редиректиться на хост.
В убунте эти тулзы можно установить из репозитария, а полученный бинарь автоматом будет запускаться через QEMU — очень удобно.
Еще некоторые враги невидимы и другие мелкие артефакты вроде отрисовки волос и бороды. На полноценную поддержку все еще не тянет. Хорошо что не так многим играм нужен SO, работает очень многое без всяких настроек и с хорошей скоростью. В некоторых играх даже плюсы есть, например в DA Origins у меня куда быстрее загрузки в лине нежели в винде. И это тулза только вышла и в бэте.
Проблема в том, что по факту это не так. Это может быть не GC, а что угодно, просто наблюдаемый факт, что драйвер чем-то занимается после реального обновления. У меня это проявляется и на Linux и на Windows. Драйверам никто не запрещает это делать, по документации все четко, ничего не нарушается. Да и от GC никуда не деться, если не на swap его выполнять (когда как раз кадр завершили и логично почистить), на идущий следом glClear()? В общем кривота это все, знать реальное время отображения нужно, без этого никуда.
Вот какую проблему решал и решил гугл.
Проблема в том что swapBuffers может висеть довольно долго и реальное отображение будет неизвестно когда в этом промежутке, это не обязательно конец swap+glFinish и подобному. Вот это расширение позволяет узнать когда же оно реально было. В будущее никто не заглядывает, просто учитываешь это при генерации следующего кадра. Тут конечно еще может быть время пока кадр дойдет до монитора, но оно обычно уже постоянное и на «stutter» уже не влияет.
В openfl из haxe программы используешь swf ассеты, которая потом транслируется в другие языки. Это не совсем флеш и поддержка swf там далеко не полная.