А ещё можно добавить задержку реакции человека, которая превышает 100 мс и скорость нервной проводимости, по которой я видел данные о 20-50 мс от возникновения сигнала в головном мозге до начала движения руки.
Чтобы изображение дёргалось рывками даже на 240 Гц?
Я думаю, вы хотели сказать про Motion-to-Light latency.
Эта задержка зависит от многих параметров: перифирия ввода, архитектура игрового движка, настройки игры, настройки видеокарты, пропускная способность видеовыхода, софт в мониторе, технологии G-Sync/Freesync… В обычных условиях она может находиться в диапазоне от 25 до 100+ мс.
Чтобы снизить эту задержку для VR до 20 мс пришлось сделать множество нетривиальных изменений в архитектуре игр, видеодрайверах и даже видеоподсистеме Windows.
Собственно, от перехода 120 Гц -> 240 Гц эта latency уменьшается очень незначительно, примерно на 4 мс.
Попробуйте посидеть день за монитором с 240 Гц, а потом переключить его в 90 Гц. Отлично видно, как скролл и анимации распадаются на отдельные кадры.
При 240 -> 120 я такого уже не вижу, только ощущаю снизившуюся гладкость интерфейса.
Я отлично вижу разницу между 90 и 120 Гц.
Между 120 и 240 для меня уже едва различимо, но профессиональные игроки в шутеры эту разницу отлично чувствуют в слепых тестах.
Геймеры в массе слышали и выбирали устройства по нему. С тех пор мало что изменилось.
а вспомнить что тогда было на телефонах так вообще труба — слайдшоу из-за хреновеньких экранов и плохой производительности
Как раз ровно 10 лет назад вышел iPhone 4, который к неплохой производительности и отзывчивости интерфейса добавил Retina экран.
да и софт был ппц, всё подряд блокировало отрисовку
Нет, конечно. Нормальные программисты и тогда разделяли потоки UI и основной работы. А с ппц софтом всё только хуже становится — electron везде, flutter заводят под лозунгом "стабильных 60 fps", которые он не может выдать даже на последних iPhone с процессором мощнее чем в моём ноуте.
Потом постепенно и инпут лаг заметили (и начали бороться, потому что потребители требовательные ныли)
Не вижу я этой борьбы. И отдельные фанатики latency тут ничего не решают.
То, что сегодня «топовые компьютеры с кучкой специфических оптимизаций» имеет все шансы через десять лет стать просто обычными компьютерами с обычными драйверами.
Это да. А вот по поводу бурного прогресса в топовых компьютерах через 10 лет у меня большие сомнения.
Пока выглядит так, что единственным реальным способом повышать разрешение и снижать задержки является отслеживание движений зрачков и отрисовка в высоком разрешении небольшой области в центре взгляда. Длительность и предсказуемость траектории саккад вполне позволяет проворачивать такой финт за время подготовки кадра.
Но вот обычным мониторам и прикладным программам это никак не поможет, как не помог гейминг в 120 Гц за последние 15-20 лет.
для шрифтов практически нет предела разрешения с которым их можно рендерить
У техники есть ограничения по pixelrate, который она может выдавать :(
И любое увеличение плотности пикселей ведёт к квадратичному росту требуемой производительности и ширины всех каналов.
А про рефреш рейт — пока запроса нет, то и программ таких не будет
Есть такой запрос — VR. Чем выше refresh rate и чем ниже общая задержка всего цикла motion-to-light, тем реалистичнее ощущается виртуальный мир. На текущих технологиях мы где-то в районе 2880x1600@144 Гц и 22 мс. Это на самых топовых компьютерах, в простых по графике играх, с кучкой специфичных оптимизаций драйверов.
У меня сейчас нет обычного айпада чтобы проверить, но, возможно, там просчитываются все анимации для 120 Гц, а потом каждый второй кадр выбрасывается и заменяется предыдущим.
Ну или просто я так привык видеть 120 Гц именно на этом устройстве.
О, я даже не знал, что оно настраивается, только с телефоном и ноутом мог сравнить ощущения.
Сейчас вот включил этот Limit Frame Rate, ну это же чудовищно!
Все анимации, скролл, перестали быть плавными. Воспринимается не как единое движение, а как подёргивания, почти как слайдшоу. Как будто iPad сломался или очень тормозит.
Ну и писать от руки с помощью Pencil у меня в таком режиме не получается: из-за отставания следа всё время ощущение непропечатавшихся чернил, как от плохо пишущей шариковой ручки.
Зачем нужен заоблачный PPI? После 300 разницу можно увидеть только разглядывая экран вплотную.
А для 1000 Гц нужно уметь полный цикл отрисовки успевать в 1 мс. При том, что сейчас многие приложения даже в 16 не всегда укладываются.
Любой скролл, в том числе страниц в браузере, все анимации, работа со стилусом.
В целом система обладает меньшим Input Lag, что для меня очень заметно.
Не, я под линуксовые сервера пишу, в основном.
Для тестов пользуюсь внешней виртуалкой, т.к. собирать и запускать что-то серьёзное на ноутбуке просто непрактично, даже без виртуализации.
Я как бы тут не согласен. Их достаточно много. И если не брать печатные машинки типа эйров. То ради таких приложений и берут маки.
С разработчиками популярных приложений Apple уже взаимодействует по поводу портирования. И, судя по тому, что они рассказывали в State of the Union, это не 1-2 компании, а гораздо больше.
И я всё ещё уверен, что такие приложения не содержат значительное количество супероптимизаций на интринсиках.
Я привел как пример, что apple опять начал пиреезжать в свое уютное и теплое окружение и выбраться из него не получится, если ты хочешь разрабатывать под них.
А зачем из него выбираться, если разрабатываешь под iOS/macOS?
Если хочется переносимой графики между macOS/Linux/Windows, то стоит использовать более высокоуровневые средства вроде Unity/UE, которые уже сделали всю работу по абстрагированию.
То же самое с GUI, с сетью и т.д.
Вот тут и главный вопрос. Я читал много комментариев от системных, фротнэнд, бекэнд разработчиков, что им важно иметь нормальную x86 виртуализацию.
Часть таких задач снимается виртуалкой на сервере, благо мест без сети сейчас не так много. Часть можно унести на ARM-виртуализацию.
Но да, некоторые вещи так не решить, и тут можно только сказать, что ARM-мак не подходит для решения таких задач и надо искать другой инструмент.
С другой стороны, сейчас возникает всё больше ARM-серверов, и для отладки ПО для них мак может оказаться вполне подходящим средством.
А ещё можно добавить задержку реакции человека, которая превышает 100 мс и скорость нервной проводимости, по которой я видел данные о 20-50 мс от возникновения сигнала в головном мозге до начала движения руки.
Чтобы изображение дёргалось рывками даже на 240 Гц?
Я думаю, вы хотели сказать про Motion-to-Light latency.
Эта задержка зависит от многих параметров: перифирия ввода, архитектура игрового движка, настройки игры, настройки видеокарты, пропускная способность видеовыхода, софт в мониторе, технологии G-Sync/Freesync… В обычных условиях она может находиться в диапазоне от 25 до 100+ мс.
Чтобы снизить эту задержку для VR до 20 мс пришлось сделать множество нетривиальных изменений в архитектуре игр, видеодрайверах и даже видеоподсистеме Windows.
Собственно, от перехода 120 Гц -> 240 Гц эта latency уменьшается очень незначительно, примерно на 4 мс.
Попробуйте посидеть день за монитором с 240 Гц, а потом переключить его в 90 Гц. Отлично видно, как скролл и анимации распадаются на отдельные кадры.
При 240 -> 120 я такого уже не вижу, только ощущаю снизившуюся гладкость интерфейса.
Я отлично вижу разницу между 90 и 120 Гц.
Между 120 и 240 для меня уже едва различимо, но профессиональные игроки в шутеры эту разницу отлично чувствуют в слепых тестах.
Panasonic в начале года показывал такое: https://na.panasonic.com/us/news/panasonic-develops-worlds-first-hdr1-capable-uhd-vr-eyeglasses
Геймеры в массе слышали и выбирали устройства по нему. С тех пор мало что изменилось.
Как раз ровно 10 лет назад вышел iPhone 4, который к неплохой производительности и отзывчивости интерфейса добавил Retina экран.
Нет, конечно. Нормальные программисты и тогда разделяли потоки UI и основной работы. А с ппц софтом всё только хуже становится — electron везде, flutter заводят под лозунгом "стабильных 60 fps", которые он не может выдать даже на последних iPhone с процессором мощнее чем в моём ноуте.
Не вижу я этой борьбы. И отдельные фанатики latency тут ничего не решают.
Это да. А вот по поводу бурного прогресса в топовых компьютерах через 10 лет у меня большие сомнения.
Пока выглядит так, что единственным реальным способом повышать разрешение и снижать задержки является отслеживание движений зрачков и отрисовка в высоком разрешении небольшой области в центре взгляда. Длительность и предсказуемость траектории саккад вполне позволяет проворачивать такой финт за время подготовки кадра.
Но вот обычным мониторам и прикладным программам это никак не поможет, как не помог гейминг в 120 Гц за последние 15-20 лет.
VirtualLink — это просто стандартизированное объединение DisplayPort + USB3.1 в один кабель.
У техники есть ограничения по pixelrate, который она может выдавать :(
И любое увеличение плотности пикселей ведёт к квадратичному росту требуемой производительности и ширины всех каналов.
Есть такой запрос — VR. Чем выше refresh rate и чем ниже общая задержка всего цикла motion-to-light, тем реалистичнее ощущается виртуальный мир. На текущих технологиях мы где-то в районе 2880x1600@144 Гц и 22 мс. Это на самых топовых компьютерах, в простых по графике играх, с кучкой специфичных оптимизаций драйверов.
У меня сейчас нет обычного айпада чтобы проверить, но, возможно, там просчитываются все анимации для 120 Гц, а потом каждый второй кадр выбрасывается и заменяется предыдущим.
Ну или просто я так привык видеть 120 Гц именно на этом устройстве.
О, я даже не знал, что оно настраивается, только с телефоном и ноутом мог сравнить ощущения.
Сейчас вот включил этот Limit Frame Rate, ну это же чудовищно!
Все анимации, скролл, перестали быть плавными. Воспринимается не как единое движение, а как подёргивания, почти как слайдшоу. Как будто iPad сломался или очень тормозит.
Ну и писать от руки с помощью Pencil у меня в таком режиме не получается: из-за отставания следа всё время ощущение непропечатавшихся чернил, как от плохо пишущей шариковой ручки.
Зачем нужен заоблачный PPI? После 300 разницу можно увидеть только разглядывая экран вплотную.
А для 1000 Гц нужно уметь полный цикл отрисовки успевать в 1 мс. При том, что сейчас многие приложения даже в 16 не всегда укладываются.
Любой скролл, в том числе страниц в браузере, все анимации, работа со стилусом.
В целом система обладает меньшим Input Lag, что для меня очень заметно.
OLED гораздо быстрее умеет переключаться и там блюр сильно менее выражен.
К сожалению, OLED-монитор для компьютера за разумные деньги пока не купить.
Сериалы часто под 50/60 к/с делают, оттуда и "эффект мыльной оперы"
Мне очень понравились качеством изделия Arm Media: https://market.yandex.ru/catalog--kronshteiny-i-stoiki/56146/list?glfilter=7893318%3A10713369&onstock=1
Использовал несколько лет кронштейны на стену, сейчас подвесил на стол 2 монитора с помощью Arm Media LCD-T42 — поразительно устойчивая конструкция получилась.
Вообще-то могут: https://en.wikipedia.org/wiki/ARM_big.LITTLE#Heterogeneous_multi-processing_(global_task_scheduling)
Это просто не используется для Rosetta 2 из-за усложнения обеспечения более строгой модели памяти x86 в присутствии разных типов ядер.
Не, я под линуксовые сервера пишу, в основном.
Для тестов пользуюсь внешней виртуалкой, т.к. собирать и запускать что-то серьёзное на ноутбуке просто непрактично, даже без виртуализации.
С разработчиками популярных приложений Apple уже взаимодействует по поводу портирования. И, судя по тому, что они рассказывали в State of the Union, это не 1-2 компании, а гораздо больше.
И я всё ещё уверен, что такие приложения не содержат значительное количество супероптимизаций на интринсиках.
А зачем из него выбираться, если разрабатываешь под iOS/macOS?
Если хочется переносимой графики между macOS/Linux/Windows, то стоит использовать более высокоуровневые средства вроде Unity/UE, которые уже сделали всю работу по абстрагированию.
То же самое с GUI, с сетью и т.д.
Часть таких задач снимается виртуалкой на сервере, благо мест без сети сейчас не так много. Часть можно унести на ARM-виртуализацию.
Но да, некоторые вещи так не решить, и тут можно только сказать, что ARM-мак не подходит для решения таких задач и надо искать другой инструмент.
С другой стороны, сейчас возникает всё больше ARM-серверов, и для отладки ПО для них мак может оказаться вполне подходящим средством.
Наверное, стоит куда-то написать, чтобы в документации отметили этот тип платформозависимым