У меня такой экспириенс с самого начала пользования (чуть позже как перешли на интел).
Ощущение старой freebsd с красивой надстройкой, которую чуть тронь — рушится.
Например lsof -K не поддерживается (как и большинство утилит показывающие треды), нормально работает с тредами только xcode. Половина опций mount тоже не поддерживается.
Все базовые пакеты древние, выручает только brew и macports, многие пакеты там с глюками.
Драйвера nvidia глючные, мне самому приходилось в шейдеры вставлять #ifdef APPLE. Справедливости ради они и под виндой и линем глючные, их считай только сейчас более менее обкатали благодаря гитхабу dxvk, и тому, что там разработчики дров тусуются. Раньше просто не было места где плакаться, я пилил посты на их форум, но там глухо. Но на маке субъективно ситуация хуже всего, и усугубляется тем, что нету Vulkan, а MoltenVK пока многое не поддерживает.
Так же я как-то зарегал apple id без кредитки (надо было только бесплатный xcode поставить, больше ничего) — так мне его заблокировали почти сразу без объяснения причин.
Быстрое устаревание я замечал и тогда, так же как и под ios. Там по работе со звуком например, от версии к версии много чего менялось без обратной совместимости и надо было обновлять.
В общем, более тяжелой платформой был только WP8, лично для меня.
Не знаю их схемы, но Janus это поддерживает, поэтому логично использовать его возможности.
То-есть с turn и записью должно происходить примерно так:
1. Json API запрос на Janus для входа участника или смотрящего.
2. Создается новый ICE канал через libnice, работают turn сервера, что указаны в конфигурации, если напрямую клиента соединить нельзя.
3. Janus получает пакеты от libnice и может залогировать потоки на диск в mjr формате. Утилитой janus-pp-rec можно потом перекодировать.
Проблем с наличием реализации turn мне кажется нет, проблема что эти сервера надо где-то хостить и иметь хорошее географическое покрытие.
Да, действительно, так-же оно требует уникальности имени колонки, а автофильтр не требует. В формулах конечно можно просто к ячейкам обращаться и при копировании таблицы он их скорректирует, но MSO вариант выглядит инкапсулирование и чище.
Мм, навскидку вот тут более менее понятно про несколько популярных методов www.youtube.com/watch?v=L07t_mY2LEU
Nvidia Fast Sync это и есть адаптация OpenGL Triple Buffering для DirectX.
При просадке очень сильно помогает, дело в том, что для глаза пропуск одного цикла отрисовки, но отображение следующего в идеальной позиции мира для этого времени воспринимается гораздо лучше, чем ошибка в позиции мира, без пропусков. Так что с расширением можно сделать чтобы движок идеально адаптировал задержку и все отрисовки были в идеальной позиции, несмотря на то, что кадры пропускаем. Более того, из-за спайков без расширения даже при упирании в vsync все равно могут быть небольшие проблемы из-за небольшого (обычно) дрожания при малом окне усреднения. Магия идеального подбора лимитера в 59гц — это все отсюда ноги растут. С расширением таких проблем нет, умеренные спайки будут незаметны вообще. Проблемы возникнут только при очень резком подскоке, тогда движок не сумеет быстро адаптировать задержку, чтобы был запас для пропуска кадров.
Да, если константа то все норм.
Проблема на самом деле была всегда. Раньше во всяких квестах и в 320x200 проблема была не заметна, а с какого-нибудь quake тиринг уже стал известной проблемой.
Еще тогда не было проблем современных драйверов, как асинхронность и рандомные спайки задержки перед уходом в свопчейн. Мы просто не знаем что это за задержка: драйвер рандомно нагружен GC, драйвер досчитывает кадр (а последний кадр в свопчейне уже ушел), или же он ожидает когда последний кадр отобразится и освободится место в свопчейне для нового (минимальное количество разное для разных методов отображения). Мы просто не можем отделить одно от другого, чтобы предсказать хотя-бы с константной погрешностью абсолютно везде. Вот как-то так все это накладывается.
Да, если взять большое окно усреднения, то при ограничении на рефреш рейте все должно быть ок пока успеваем, но все станет очень плохо при просадках, что неприемлимо. Малое окно усредненеия — мешают спайки задержки. Такие дела. Задержать кадр тоже нельзя, при Fast Sync их там 3 штуки. Вот он кадр, готов, мы специально его рассчитали через синк, потому что знали что не успеем. Ждать опустошения очереди, а потом ударными темпами наполнять?
Вот только зачем все это шаманство, когда можно знать точно и можно намеренно пропуситить отображения, если знаешь что не успеешь? Все как раз куда проще становится.
PS: Я по факту делал распечатку дельты между тем, что выдает расширение и обычным предсказанием. Увы не всегда она менялась плавно чтобы быть незаметной.
PS2: Вот еще показательное видео www.youtube.com/watch?v=mVNRNOcLUuA
даже при наличии freesync и gsync из коробки идеально может и не заработать, надо шаманить.
Гугл в названии, потому что это гугловое расширение, но десктопными драйверами поддерживается.
Проблема в том, когда мы мир рассчитываем, мы предполагаем когда он должен отрисоваться. Если мы ошибемся и эта ошибка между кадрами будет не константой — будет неплавность.
Еще проблема в том, что какая хардваря и конфигурация системы мы не знаем, из-за этого условие выше очень трудно соблюсти. Стандартный метод когда мы измеряем время между уходами кадра в свопчейн и вычисляем некий средний fps, по которому находим точку во времени куда передвинуть мир (на сколько фиксированных дельт сдвинуть если у игры фиксированный таймер обработки мира) может сработать хорошо, а может и не сработать. И факторов почему это произошло к сожалению много.
Чтобы победить тиринг, достаточно методов презентации. А вот чтобы корректно проводить рассчет мира, замеров на уходе кадра в свапчейн недостаточно. Нужно знать реальные времена отображения, причем неважно переменная дельта в игре используется или постоянная с высоким fps. Я пробовал использовать что-то типа noise фильтра в измерениях, но не получилось, уж больно разных характер искажений на разном железе; VK_STRUCTURE_TYPE_PRESENT_TIMES_INFO_GOOGLE — зе бест.
В играх часто 2 режима добавляют, exclusive fullscreen — в нем отключается; и fullscreen windowed (или borderless windowed), в нем нет, но из-за отсутствия возможной пере-инициализации переключение между игрой плавнее. Но на самом деле у обоих режимов бывают свои глюки, вот например для borderless steamcommunity.com/app/292030/discussions/0/615085406652736452
Для абсолютной плавности, кстати, нужен еще VK_STRUCTURE_TYPE_PRESENT_TIMES_INFO_GOOGLE, другого пути пока нет, даже используя свопчейн и любой из методов презентеции включая freesync, gsync, Fast Sync etc. Оно конечно может и без него хорошо заработать, но не на любой хардваре, не в любом случае.
Не только оверлеи. Я не уверен есть ли в современных WM опция делать это автоматом, но вообще есть сообщение _NET_WM_BYPASS_COMPOSITOR, которое все современные фреймворки посылают для фулскрина и композитор отключается (если WM конечно нормальный).
Есть менее мертвый и более легковесный аналог gameswf — github.com/lieff/lvg
В плане движка в нем работает больше флешек чем в gameswf, но в gameswf более полная поддержка ActionScript. На данный момент это основная проблема, проходит всего 139 тестов из 2к. Вторая проблема — сделать аналог Nvidia Path Rendering без карт Nvidia, различие в скорости там разительное, хотя она вроде в любом случае выше аналогов.
То что это потенциально чувствительные данные. Для парсера достаточно слать колстеки, регистры и минидамп (и то если пользователь разрешил), нам всегда помогало. По той же причине делается минидамп, а не полный дамп (для калькулятора размер не должен быть проблемой), хотя он куда более как полезен бы был.
Тоже достаточно мощный.
Ощущение старой freebsd с красивой надстройкой, которую чуть тронь — рушится.
Например lsof -K не поддерживается (как и большинство утилит показывающие треды), нормально работает с тредами только xcode. Половина опций mount тоже не поддерживается.
Все базовые пакеты древние, выручает только brew и macports, многие пакеты там с глюками.
Драйвера nvidia глючные, мне самому приходилось в шейдеры вставлять #ifdef APPLE. Справедливости ради они и под виндой и линем глючные, их считай только сейчас более менее обкатали благодаря гитхабу dxvk, и тому, что там разработчики дров тусуются. Раньше просто не было места где плакаться, я пилил посты на их форум, но там глухо. Но на маке субъективно ситуация хуже всего, и усугубляется тем, что нету Vulkan, а MoltenVK пока многое не поддерживает.
Так же я как-то зарегал apple id без кредитки (надо было только бесплатный xcode поставить, больше ничего) — так мне его заблокировали почти сразу без объяснения причин.
Быстрое устаревание я замечал и тогда, так же как и под ios. Там по работе со звуком например, от версии к версии много чего менялось без обратной совместимости и надо было обновлять.
В общем, более тяжелой платформой был только WP8, лично для меня.
То-есть с turn и записью должно происходить примерно так:
1. Json API запрос на Janus для входа участника или смотрящего.
2. Создается новый ICE канал через libnice, работают turn сервера, что указаны в конфигурации, если напрямую клиента соединить нельзя.
3. Janus получает пакеты от libnice и может залогировать потоки на диск в mjr формате. Утилитой janus-pp-rec можно потом перекодировать.
Проблем с наличием реализации turn мне кажется нет, проблема что эти сервера надо где-то хостить и иметь хорошее географическое покрытие.
Просто к имени колонки/фильтра это не относится, они отдельно.
www.youtube.com/watch?v=L07t_mY2LEU
Nvidia Fast Sync это и есть адаптация OpenGL Triple Buffering для DirectX.
При просадке очень сильно помогает, дело в том, что для глаза пропуск одного цикла отрисовки, но отображение следующего в идеальной позиции мира для этого времени воспринимается гораздо лучше, чем ошибка в позиции мира, без пропусков. Так что с расширением можно сделать чтобы движок идеально адаптировал задержку и все отрисовки были в идеальной позиции, несмотря на то, что кадры пропускаем. Более того, из-за спайков без расширения даже при упирании в vsync все равно могут быть небольшие проблемы из-за небольшого (обычно) дрожания при малом окне усреднения. Магия идеального подбора лимитера в 59гц — это все отсюда ноги растут. С расширением таких проблем нет, умеренные спайки будут незаметны вообще. Проблемы возникнут только при очень резком подскоке, тогда движок не сумеет быстро адаптировать задержку, чтобы был запас для пропуска кадров.
Проблема на самом деле была всегда. Раньше во всяких квестах и в 320x200 проблема была не заметна, а с какого-нибудь quake тиринг уже стал известной проблемой.
Еще тогда не было проблем современных драйверов, как асинхронность и рандомные спайки задержки перед уходом в свопчейн. Мы просто не знаем что это за задержка: драйвер рандомно нагружен GC, драйвер досчитывает кадр (а последний кадр в свопчейне уже ушел), или же он ожидает когда последний кадр отобразится и освободится место в свопчейне для нового (минимальное количество разное для разных методов отображения). Мы просто не можем отделить одно от другого, чтобы предсказать хотя-бы с константной погрешностью абсолютно везде. Вот как-то так все это накладывается.
Да, если взять большое окно усреднения, то при ограничении на рефреш рейте все должно быть ок пока успеваем, но все станет очень плохо при просадках, что неприемлимо. Малое окно усредненеия — мешают спайки задержки. Такие дела. Задержать кадр тоже нельзя, при Fast Sync их там 3 штуки. Вот он кадр, готов, мы специально его рассчитали через синк, потому что знали что не успеем. Ждать опустошения очереди, а потом ударными темпами наполнять?
Вот только зачем все это шаманство, когда можно знать точно и можно намеренно пропуситить отображения, если знаешь что не успеешь? Все как раз куда проще становится.
PS: Я по факту делал распечатку дельты между тем, что выдает расширение и обычным предсказанием. Увы не всегда она менялась плавно чтобы быть незаметной.
PS2: Вот еще показательное видео www.youtube.com/watch?v=mVNRNOcLUuA
даже при наличии freesync и gsync из коробки идеально может и не заработать, надо шаманить.
Проблема в том, когда мы мир рассчитываем, мы предполагаем когда он должен отрисоваться. Если мы ошибемся и эта ошибка между кадрами будет не константой — будет неплавность.
Еще проблема в том, что какая хардваря и конфигурация системы мы не знаем, из-за этого условие выше очень трудно соблюсти. Стандартный метод когда мы измеряем время между уходами кадра в свопчейн и вычисляем некий средний fps, по которому находим точку во времени куда передвинуть мир (на сколько фиксированных дельт сдвинуть если у игры фиксированный таймер обработки мира) может сработать хорошо, а может и не сработать. И факторов почему это произошло к сожалению много.
Чтобы ситуацию с прогнозом улучшить, гугл добавил 2 вещи: обратная связь от свапчейна, когда были реальные времена отрисовки и указание желаемого времени отображения.
Есть пример github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/demos/cube.c#L1120
лучше чем он я наверно не расскажу.
Для абсолютной плавности, кстати, нужен еще VK_STRUCTURE_TYPE_PRESENT_TIMES_INFO_GOOGLE, другого пути пока нет, даже используя свопчейн и любой из методов презентеции включая freesync, gsync, Fast Sync etc. Оно конечно может и без него хорошо заработать, но не на любой хардваре, не в любом случае.
В плане движка в нем работает больше флешек чем в gameswf, но в gameswf более полная поддержка ActionScript. На данный момент это основная проблема, проходит всего 139 тестов из 2к. Вторая проблема — сделать аналог Nvidia Path Rendering без карт Nvidia, различие в скорости там разительное, хотя она вроде в любом случае выше аналогов.