Откуда берутся лаги

 

Сразу оговорюсь, что лаги в играх бывают сетевые - это когда данные с сервера вовремя не приходят на клиент (и наоборот) и локальные - когда сама игра не успевает среагировать на действия пользователя. Грубо говоря: если ваш танк плавно отзывается на управление, а другие танки ведут себя странно - мы имеем дело с сетевым лагом; если вы не можете управлять своим танком, картинка замирает на короткое время и падает FPS - лаг локальный. Так вот, эта часть о локальных лагах. На самом деле, есть еще лаги ввода - о них позже.

 

Итак. Чтобы мы видели плавную картинку, приложение должно успеть подготовить новый кадр за отведенное время. В случае с монитором с частотой обновления 60 Гц это ~16.6 миллисекунд - 1000 / 60. В случае со 120-ти герцовым монитором - ~8.3 миллисекунды. Почему так? Потому что время подготовки кадра может быть разным - 1 миллисекунда, 4, 10 - не важно, но частота обновления монитора постоянна, и если приложение не укладывается - пользователь наблюдает предыдущий кадр вместо нового на протяжении еще 16.6 мс и, разумеется, не очень доволен. Снова не успевает - пользователь видит три одинаковых кадра целых 49.8 мс и совсем в ярости. (На самом деле только если это происходит часто, но мы же любим драматизировать!)

 

Приложение не может сказать монитору "подожжи, сейчас дорисую!" или "готово, выводи!" - оно вынуждено подстраиваться под частоту обновления монитора. Этот механизм называется вертикальной синхронизацией или v-sync. Можно представить это так (извините за колхоз):

                    
Получается, у приложения есть достаточно времени, чтобы подготовить каждый кадр и переместить его в специальную область видеопамяти, откуда в назначенную миллисекунду монитор его прочитает и выведет. Но это в идеальном мире. А что если приложение замешкается и справится, скажем, за 20 мс?

                    

             

До того момента, как окончена подготовка нового кадра, в той области памяти находится предшествующий кадр. Его мы и увидим вновь.

 

Теперь представим еще менее идеальный мир. В случае с ТО приложение - это браузер, а сам клиент - это сайт. Следовательно, помимо отрисовки наших танчиков нужно еще скомпоновать страницу - совместить изображение из битвы с интерфейсом на HTML5. И сам интерфейс браузера нужно также отрисовать. Но мы же жестокие, и менее идеальный мир нас все еще не торкает. Ухудшим его! Браузер работает в операционной системе, у которой есть оконный интерфейс рабочего стола, и необходимо объединить вывод браузера с окошечком на фоне нескучных обоев. Итого:

Мы все говорим об отрисовке, но рисовать ведь целесообразно лишь обновленное состояние приложения. Значит прежде чем браться за рисование, приложение обрабатывает ввод, производит некоторые вычисления, и только затем вызывает функции рендеринга. У нас ввод - это нажатия клавиш, движения мыши и данные, полученные по сети с сервера. Вот как это выглядит:

 

 

Здесь клиент обновляет битву, отрисовывает кадр и сразу же обрабатывает информацию с сервера, которая будет использована в следующих кадрах. Все хорошо: игре удалось подготовить новый кадр, а браузеру скомпоновать страницу за ~8 мс (обработка сетевых данных не мешает выводу). Но не все бывает так гладко:

 

 

Что мы видим? Первый кадр из трех обрабатывается быстро, но напоследок прилетают сетевые данные. И еще. И еще. Второй фрейм начинает готовиться позже чем нужно, так еще и просчитывается долго. В общем, до обновления эрана мы не успели. Монитор не ждет.

 

"Подумаешь, какие-то лишние 16.6 мс!" - могут возразить некоторые. Я предлагаю думать так: на короткое время ваш 60-ти герцовый монитор превращается в 30-ти герцовый. Для динамичных игр, тем более шутеров, чрезвычайно важна стабильность. Нет, не высокий FPS! К низкому, но стабильному FPS можно привыкнуть, а вот к чему привыкнуть нельзя, так это к непредсказуемым подергиваниям изображения. Вот почему 57 фэпээс гораздо, гораздо хуже 60-ти - и разница по пользовательскому опыту здесь далеко не в трех кадрах.

 

Надеюсь, этого объяснения достаточно для понимания нижесказанного. Теперь по проблемам клиента, способным вызывать описанные микролаги.

 

Однопоточность

 

Все операции клиент выполняет последовательно в одном и - что немаловажно - основном потоке браузера. Это означает, что обработка сетевых данных и управления, обновление состояния битвы (в т. ч. просчет физики) и отрисовка результата взаимосвязаны и не могут происходить независимо друг от друга. Любая задержка по вине логической части отодвигает отображение с риском вылететь за пределы условных 16.6 мс с отчетливо ощутимым игроком лагом.

 

Как это реализовано в "нормальных" играх? Два потока: поток отрисовки - выполняет рендеринг как можно быстрее, поток логики - одновременно просчитывает мир, затем передает его состояние потоку отрисовки, при этом задержки в логике не так сильно сказываются на пользовательском опыте.

 

Что могут сделать разработчики: вынести обработку сетевых событий и внутриигровую логику в отдельный поток (workers, offscreen canvas).

 

Что могут сделать игроки: выбирать процессор с высокой производительностью на ядро; использовать профиль питания "Максимальная производительность", повышающий частоту процессора и минимизирующий скачки во времени обновления/отрисовки.

 

Дозагрузки "по ходу пьесы"

 

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

 

Что могут сделать разработчики: предзагружать ресурсы во время нахождения в лобби и поиска битвы; добавить соответствующие настройки.

 

Сломанный v-sync в Chrome

 

Здесь интереснее. В некоторых случаях система способна сильно урезать точность вертикальной синхронизации. То есть вместо идеальных 16.6 мс до обновления экрана браузер и игра могут "очнуться" многим позже и не успеть выполнить процедуры отрисовки. Дело в том, что Хром использует способ синхронизации, подверженный сильному джиттеру (отклонениям во времени между вызовами), в частности при питании ноутбука от батарейки. И эти отклонения катастрофические. Энтузиасты даже сделали сайт, демонстрирующий сей эффект наглядно - vsynctester.com

 

На моем древнем, но не самом слабом (i5, 860m) ноутбуке, который я специально откопал для тестов, переход на питание от аккумулятора приводит к неистовым скачкам всех графиков, не говоря уже о проверочной надписи "vsync", которая в идеале должна быть постоянно серой. И каждый такой скачок - потенциальный лаг в игре.

 

Что могут сделать игроки: никогда не играть при питании от батарейки; отключить вертикальную синхронизацию.

 

Инпут лаг aka "пьяная камера"

 

Чтобы продемонстрировать инпут лаг наглядно и в ТО, можно открыть гараж и повертеть мышкой танчик. Курсор выводится с минимальной задержкой. Танчик же проходит все круги ада. Чувствуете? Танчик отзывается не мгновенно, а будто догоняет курсор, "пружинит", whatever. Еще более наглядная иллюстрация доступна на все том же сайте - vsynctester.com/game.html Поставьте галочку рядом с "Show software cursor" и ужаснитесь. Это и есть инпут лаг - время между совершением действия и отображением результата на экране. И здесь вновь стоит поблагодарить Хром: задержка ввода на нем, вероятно, гораздо больше, чем могла бы быть. 

 

Вспомним интерфейс операционной системы, который во всех вышеперечисленных примерах заменяет "вывод" на "скомпоновать окна, панель задач и нескучные обои и вывести через 16.6 мс":

 

        
Отмечу, что этап "ОС" никогда не "тормозит" браузер на 16.6 мс, так как приложения выполняют отрисовку не напрямую в область памяти монитора, но в промежуточный буфер ОС:

 

"Особенность" Хрома в том, что из-за бага, который не исправляется почти шесть лет получается вот что:

В общем, между тем, как вы, например, прикажете танку ехать вперед нажав на соответствующую кнопку и моментом, когда вы увидите движение на экране... ну, как сказать...

Забавно, что разработчики стараются пересадить игроков на мышь, с которой инпут лаг ощущается гораздо сильнее. Как эту проблему решают клиентские игры? У них нет Хрома и во многих случаях (в полноэкранном режиме) нет компоновки уровня ОС. Результат - инпут лаг вдвое меньше.

 

Что могут сделать игроки: отключить v-sync.

 

Отключение v-sync - не всегда выход

 

Отключение синхронизации приводит к такой картине:

                    
Браузер не ждет следующего обновления экрана, а сразу начинает подготовку кадра, что сильно помогает при FPS ниже 60. Однако нестабильное время отрисовки никуда не девается, и при частоте выше целевой на монитор выводятся фреймы разной "давности" - от 1 мс (условно) до бесконечности. В один момент мы можем увидеть мир в состоянии, близком к последнему, в следующий - на 12 мс раньше. Разумеется, это сказывается на плавности анимаций и комфорте управления. Данный недостаток нивелируется на высоких фреймрейтах, но вот загвоздка: клиент ТО не способен держать стабильно высокий фреймрейт. На мощном компьютере он постоянно прыгает от 120 до 1000, на счетчике кадров красуется среднее число 560, но корова, как известно, утонула в реке, где ей в среднем было по колено. Почему так происходит (я не про корову, а про скачки во времени отрисовки), надеюсь, догадываетесь.

Что могут сделать разработчики: многопоточность.

Что могут сделать игроки: если отключаете v-sync - при возможности выставляйте ограничение максимум в 120 кадров в панели управления видеокартой.

 

Серые экраны смерти

 

Помните проблему с утечкой памяти, приводившей к серым экранам у многих игроков? Так вот, утечку памяти разработчики устранили, однако она - не единственная причина, по которой могут возникать серые экраны. Серый или черный экран - это потеря контекста. Контекст - это набор данных (например, текстур) и состояний, позволяющих игре пользоваться аппаратным ускорением для вывода изображения. Шокирующий факт: контекст может теряться по множеству причин, не зависящих от игры, нехватка видеопамяти - только одна из них. Шокирующих факт 2: игра не знает о потере контекста и не умеет его восстанавливать. А ведь техническая возможность восстанавливать контекст давно существует, более того - во многих "best practices" разработки для браузера советуется реализовывать восстановление контекста. Что это означает для игрока? Вместо серого экрана и полного перезапуска клиента - небольшое подтормаживание и дальнейшая нормальная игра.

 

Еще у меня припасен Самый Шокирующий Факт. Утечка видеопамяти была устранена за полгода. У меня есть все основания полагать, что так произошло в том числе из-за того, что разработчики просто-напросто не подозревали о масштабе бедствия. Как я уже говорил, для ТО серый экран - нормальное состояние, клиент не только не умеет восстанавливать контекст - он продолжает работать как ни в чем не бывало. Игра не генерирует исключение и информация о нем не передается в систему учета ошибок. Представляете, да? Тысячи или, может быть, даже десятки тысяч игроков мучились с серыми экранами, а разработчики смотрели в свою систему и видели: все нормально, никаких проблем нет, только на форуме три человека жалуются. Прямо сейчас, возможно, некоторые игроки сталкиваются с серыми экранами - разработчики не знают об этом и отодвигают реализацию восстановления контекста как неприоритетную задачу.

 

Добавлю еще, что система учета ошибок работает мягко говоря неидеально. Запросы к ней практически всегда неудачные. Может быть она перегружена, не знаю. В любом случае для разработчиков и другие проблемы выглядят менее распространенными, чем они есть.

 

Что могут сделать разработчики: реализовать восстановление контекста; починить систему учета ошибок.

 

Прожорливое сглаживание

 

Чтобы избежать неприятного артефакта - "лесенок" по краям объектов - игры используют разные методы антиалиасинга. Клиент ТО говорит браузеру "сделай антиалиасинг за меня", ну а браузер применяет метод множественной выборки или MSAA. Проблема в том, что этот способ медленный и потребляет непомерное количество видеопамяти (в случае с 4K - 1 Гб плюсом!), и в "больших" играх давно вытеснен более современными и эффективными FXAA, SMAA, TAA и другими. Включение MSAA - последнее, что ты делаешь, и то только после того, как выставил остальные настройки на "ультра".

 

Оцените: клиент работает в окружении, где лишняя миллисекунда в отрисовке - это лаг, а лишний мегабайт - часто серый экран, тем не менее он задействует один из самых прожорливых методов сглаживания.

 

Что могут сделать разработчики: запилить "легкий" метод сглаживания для слабых компьютеров и добавить опцию в настройки.

 

Что могут сделать игроки: если вы испытываете проблемы с FPS, но не хотите играть совсем без сглаживания и у вас видеокарта Nvidia - для скачиваемого клиента доступен метод FXAA в панели управления видеокартой.

 

 

Итог.

 

Я ни в коем случае не хочу сказать, что новый клиент никуда не годится и на нем невозможно играть. Нет, на множестве конфигураций он способен демонстрировать на счетчике кадров заветные 60 ФПС, но вот в чем он терпит неудачу в большинстве случаев - так это в предоставлении т. н. smooth user experience. Даже если вы включите профиль "Высокая производительность", подсоедините ноутбук к сети, отключите вертикальную синхронизацию, выставите ограничение в панели управления - все равно вы периодически будете ощущать микролаги.

 

Время подготовки кадра - катастрофа. И эта катастрофа помножается на особенности браузерного окружения. В играх разработчики стараются минимизировать frame time в т. ч. используя многопоточность и дробя большие задачи на мелкие. В ТО мы наблюдаем картину, когда время между двумя фреймами может отличаться в 2-4 раза без всякой видимой на то причины иногда доходя до 8-12 мс. Вертикальная синхронизация маскирует эту разницу, но сама является проблемой.

 

Кто-то может вспомнить две буквы - GC. Вот GC:

 

 

А вот клиент ТО:

 

 

И я замечу, что такое случается на i7 с постоянной частотой 4.2 ГГц. Что там будет на ноутбуках с низковольтными процессорами - страшно представить.

 

А ведь ТО - браузерная игра и она должна "просто работать" без танцев с бубном со стороны игрока. Клиент должен быть стабилен как скала, а не вял и капризен как весенний цветочек, на который боишься дунуть. Ноутбуки - не будущее, а уже давно настоящее. Если разработчики все еще позиционируют ТО как преимущественно браузерную (нет) игру - им стоит подумать, что чувствует пользователь, запустивший игру впервые без предварительной настройки системы.

 

Изменено 8 декабря, 2020 пользователем Niced

Уважение за потраченное время, но... зачем?)) Серьёзно, почему ты разбазариваешь свою хорошую техническую подкованность на написание статей для ТОшки? Пиши на Хабре, куда заглядывают довольно много людей, желающих познать IT технологии, а не на форуме для 15 человек, дочитают из которы 5, поймут два )

22 минуты назад, Niced сказал:

Если разработчики

Подводя итог: будущего у ТО нет...

А что там по оверхеду от профайлера?)

4 minutes ago, AAoE said:

Пиши на Хабре, куда заглядывают довольно много людей, желающих познать IT технологии, а не на форуме для 15 человек, дочитают из которы 5, поймут два )

Есть мнение, что лучше быть первым парнем на деревне, чем вторым в городе

 

Хотя сейчас на хабре очень не хватает нормальных техностатей, одно УГ от корпоративных аккаунтов.

 

33 minutes ago, Niced said:

А ведь техническая возможность восстанавливать контекст

Там предлагают "re-setup all your WebGL state and re-create all your WebGL resources when the context is restored"

Насколько это сложно в реализации в игре?

 

Ну и как минимум они ивент потери контекста обрабатывают. Что там происходит - фз)

 

23 minutes ago, Niced said:

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

А мне кажется, что неработающая sentry это не баг, а фишка - типа, включают её по большим праздникам, чтобы логи не забивать каждый день одним и тем же.

2 минуты назад, Serene сказал:

А что там по оверхеду от профайлера?)

Ну, я тебе предоставлял информацию со своего скрипта без всяких профайлеров. Там все то же самое. Только он еще не фиксировал сетевые ивенты, которые, как выяснилось, тоже отъедают.

 

3 минуты назад, Fizzika сказал:

Там предлагают "re-setup all your WebGL state and re-create all your WebGL resources when the context is restored"

Насколько это сложно в реализации в игре?

Настолько же сложно, насколько сложно подготовить контекст изначально. Можно использовать тот же код. Да, это небыстро, но всяко несоизмеримо быстрее, чем перезапускать клиент, так еще со сбросом всех кэшей в памяти.

46 minutes ago, Niced said:

Время подготовки кадра - катастрофа.

Я довольно редко сталкивался с тем, чтобы с этим была прям реально катастрофа.

Пару раз бывало смотришь - фпс вроде 150-170, а всё дёрганное. Но это всё скорее исключение, обычно всё двигается достаточно плавно, по крайней мере уж точно лучше флеша.

 

После хтмл с отключенным фпс-локом на флеше я играть совсем не мог - дёргнаность на скачущих 52-60 фпс максимально бесила.

1 minute ago, Niced said:

Настолько же сложно, насколько сложно подготовить контекст изначально

Ну так это будет выглядеть наверное как такая лайт-перезагрузка в бой.

Мне сложно представить, что вот у тебя контекст потерялся, твой танк завис на 2-3 секунды, и всё, все текстуры загрузились в видеопамять, все шейдеры скомпилировались и тоже загрузились, и ты дальше поехал нагибать.

Только что, Fizzika сказал:

все текстуры загрузились в видеопамять, все шейдеры скомпилировались и тоже загрузились, и ты дальше поехал нагибать.

С многопотоком (когда основной поток существует только для прокачки ивентов в воркеры и финального рендеринга сцены)  даже останавливать нагиб не надо, продолжаешь нагибать вслепую пока там контекст восстанавливается ))

 

Я бы без хорошего бенчмаркинга не стала всерьёз говорить про обработку инпута и всего-всего в разных потоках. Очень возможно что накладные расходы на межпоточное взаимодействие (в частности сериализацию-десериализацию) превысят какой-либо бонус от этой многопоточности, особенно на каких-нибудь U процессорах. Это не значит что её (многопоточность) нельзя вовсе использовать, но не в таком виде. 

10 минут назад, Fizzika сказал:

А мне кажется, что неработающая sentry это не баг, а фишка - типа, включают её по большим праздникам, чтобы логи не забивать каждый день одним и тем же.

Иногда она все-таки отвечает. Один раз из пяти может быть. Как-то так.

 

3 минуты назад, Fizzika сказал:

Я довольно редко сталкивался с тем, чтобы с этим была прям реально катастрофа.

А я не могу играть с выключенным v-sync и без ограничения в панели управления. Прыжки от 800 до 200 - просто больно. Плюс там еще у GC не получается вклиниться с быстрыми сборками в idle time и периодически он запускает полную, что тоже сказывается.

 

1 минуту назад, Fizzika сказал:

Мне сложно представить, что вот у тебя контекст потерялся, твой танк завис на 2-3 секунды, и всё, все текстуры загрузились в видеопамять, все шейдеры скомпилировались и тоже загрузились, и ты дальше поехал нагибать.

Зависит от пропускной способности оперативной и видеопамяти. Я был удивлен, насколько быстро текстуры загружаются в VRAM, по крайней мере у меня. А так да, лайт-перезагрузка. Но это всяко лучше :)

1 час назад, Niced сказал:

Что могут сделать разработчики: предзагружать ресурсы во время нахождения в лобби и поиска битвы; добавить соответствующие настройки.

А таки что там по текстурным атласам?)

1 minute ago, Niced said:

Прыжки от 800 до 200 - просто больно

Можно какой-то скрипт для замера фпс c минимальным оверхедом и выхлопом в csv написать?

Было бы интересно проанализировать, потому что у меня таких скачков нет.

 

1 час назад, Fizzika сказал:

 csv 

Страшный ты человек.

Чем тебе дедушка Xмель/ дядя Джсон не угодили?(

 

Кстати, вот что реально бесит в хтмл, так это то, что нельзя забиндить дополнительные кнопки на мышке на игровые действия.

Причём никак ограничений со стороны браузера нету, я проверял.

 

У меня пока два варианта на этот счёт - переназначить на уровне ОС эти кнопки на кнопки клавы (что ниочень, так как они перестанут выполнять функции назад-вперёд в браузере), или написать юзерскрипт, который будет перехватывать нажатия этих кнопок и файрить клавиатурные ивенты. Но тут проблема в том, что никак не могу найти, на каком элементе танковый обработчик висит. Протестил window, document и все канвасы - пусто.

3 minutes ago, WALLE said:

Чем тебе дедушка Xмель/ дядя Джсон не угодили?(

А зачем для простого списка значений что-то сложнее csv?)

Ну джсон то ещё ладно, но вот хмл это прям совсем жесть какая-то))

1 hour ago, Niced said:

На моем древнем, но не самом слабом (i5, 860m) ноутбуке, который я специально откопал для тестов, переход на питание от аккумулятора приводит к неистовым скачкам всех графиков

Даже при выставленном режиме "максимальная производительность" в панели управления?

 

1 час назад, Fizzika сказал:

А зачем для простого списка значений что-то сложнее csv?)

Ну джсон то ещё ладно, но вот хмл это прям совсем жесть какая-то))

Для единства стандарта главным образом.

Плюс - ты ж потом захочешь небось еще туда что-нить прикрутить))

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

12 минуты назад, Fizzika сказал:

Даже при выставленном режиме "максимальная производительность" в панели управления?

 

Режим не имеет к этому никакого отношения, насколько мне удалось понять. Важен источник питания.

 

26 минут назад, Fizzika сказал:

Можно какой-то скрипт для замера фпс c минимальным оверхедом и выхлопом в csv написать?

Конечно можно! Хороший ответ, да?

 

32 минуты назад, Serene сказал:

А таки что там по текстурным атласам?)

Да хотя бы предзагружать то, что есть. Если даже я такой скриптик смог набросать - значит это не так сложно.

3 minutes ago, WALLE said:

Для единства стандарта главным образом.

csv вполне себе стандарт для построения всяких графиков и представления "плоских", а не древовидных данных. Тот же csv я смогу импортнуть в excel и сразу построить графики и посчитать статистические метрики - да и с matplotlib никаких дополнительных заморочек не возникнет.

 

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

Конечно, и джсон тоже можно сразу отдавать на лету, но это тоже какие-то дополнительные телодвижения.

 

3 minutes ago, WALLE said:

Плюс - ты ж потом захочешь небось еще туда что-нить прикрутить))

Так никаких проблем нет, структура то у меня не изменится, в любом случае это будет или список, или таблица. И то, и другое для csv более чем подходит.

Иерархии в этой предметной области уж точно никакой не будет.

 

7 minutes ago, WALLE said:

от общепринятого джсона

Да не надо лочиться на одном стандарте, разные штуки хороши в разных предметных областях и ситуациях, тащить джсон-комбайн вот в такую простую утилиту я не вижу ни малейшего смысла.

12 минуты назад, WALLE сказал:

Для единства стандарта главным образом.

csv это прекрасный стандарт для представления табличных данных без оверхедов на (де)сериализацию и вообще человековосприятия этих самых данных )

8 минут назад, Niced сказал:

Да хотя бы предзагружать то, что есть.

А куда предзагружать? В память браузера оно предзагружается при первой загрузке в бой, атласы текстур предзагружаются и в видеопамять, а что ещё?

 

Помню во многих онлайн проектах можно было буквально "почувствовать" приближение врага. Когда случался такой легкий лаг при его появлении в локации %)

6 minutes ago, Niced said:

Режим не имеет к этому никакого отношения, насколько мне удалось понять. Важен источник питания.

То есть это на уровне биоса/микрокода понижаются максимальные частоты, и ты никак это не исправишь?

Звучит как какой-то сюр.

 

Я вот не знаю, прошёл ли бы я на своём компе слепой тест на игру с/без зарядки

8 минут назад, Serene сказал:

А куда предзагружать? В память браузера оно предзагружается при первой загрузке в бой, атласы текстур предзагружаются и в видеопамять, а что ещё?

Блин.  Открой профайлер, зайди в битву и увидишь, что там догружается по ходу. Среди ресурсов - даже какие-то 3ds-ки.

 

4 минуты назад, Fizzika сказал:

То есть это на уровне биоса/микрокода понижаются максимальные частоты, и ты никак это не исправишь?

Звучит как какой-то сюр.

Там не в частотах дело, а в точности синхронизации. Винда предоставляет более точный способ, но Хром им не пользуется. И это только на Винде, да.

6 минут назад, Niced сказал:

что там догружается по ходу

Я пропустила момент когда они это доделали. Ленивая загрузка ресурсов была прерогативой флеша, отчасти поэтому была такая разница в скорости загрузки

Только тут ничего плохого нет, загрузка ресурсов не выполняется синхронно, а то что оно там распаковывается - аще пофиг. После первого боя (особенно 16х16) уже все нужные ресурсы загружены, может кроме каких-нибудь красок

2 hours ago, Niced said:

Что могут сделать разработчики: ...

 

    До кучи, я б добавил:
        * попробовать компилировать в webassembly, а не жавускипт (не в курсе, правда, как там с этим у Котлина),
        * отключать алгоритм Нейгла для своих веб-сокетов.

2 минуты назад, DieHard_5 сказал:

 * отключать алгоритм Нейгла для своих веб-сокетов.

Он у тебя каким-то образом включен? оО

17 минут назад, DieHard_5 сказал:

* попробовать компилировать в webassembly, а не жавускипт (не в курсе, правда, как там с этим у Котлина),

Есть Kotlin/WASM, он в разработке. Только там тоже свой GC, который не факт что умеет так же красиво выполнять сборку между фреймами.

Изменено 8 декабря, 2020 пользователем Niced