Определение быстродействия ПК клиента

litebox · 02.04.2009, 17:49

Есть флэшка с большой областью перерисовки. Есстественно, на многих ПК тормозит

. Есть идея динамически менять stage.quality + не выводить некоторые элементы дизайна в зависимости от мощностей системы.
Идея такая: в определенный момент (когда начинает загружаться флэш-контент) запускать на выполнение цикл действий, засекать время его выполенения и на основе этого интервала судить о мощности ПК.
Вопросов 2:
1. какую задачу следует выбрать для проверки, например, создание и заполнение массива данными, или создание и добавление/удаление в конвеер MovieClip'ов?
2. следует ли делать это в цикле for или while (что в любом случае приведет к подвисанию машины на момент теста) или разместить итерацию этого цикла в Event.ENTER_FRAME, чтобы проводить операцию в фоне?
Вообще интересны любые мысли по поводу этой затеи

etc · 02.04.2009, 18:39

Дайте пользователям самостоятельно выбирать качество рендера.

Dimonte · 02.04.2009, 19:41

Я такой тест делал тремя запусками сравнительно короткого действия: заполнение BitmapData шумом, потом применение фильтров на нем. Замерял время, вычислял среднее и сравнивал с заранее заданными величинами.

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

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

Наконец, про приоритет операции. На фоне проводить, конечно, "красивее", но вы уверены, что результаты не будут сбиты каким-то действием пользователя? Если все-таки решите делать фоновой операцией, посмотрите на очень приятную реализацию green thread'а http://blog.generalrelativity.org/?p=29

litebox · 02.04.2009, 23:12

Цитата:

Дайте пользователям самостоятельно выбирать качество рендера.

Без условно, это верное решение, но оно идет, как заметил Dimonte, "в конфликт с интерфейсом". Да и специфика игр такова, что играют в них взрослые дяди-тети, которых такая свобода выбора испугает

.
То, что процессор может быть сильно занят во время теста, это хорошее замечание, так можно "опустить" до низкого качества вполне хорошую машину.
Проводить тест думаю именно при старте загрузки контента - в этот период юзер ничем не управляет и повлиять на выполнение теста не сможет.
В качестве фреймрейта используется ENTER_FRAME, про использование таймера как то не задумывался, даже не знаю, это может дать какой-то выигрыш, или это не принципиально?

kirea · 02.04.2009, 23:46

использование таймера вместо ENTER_FRAME дает огромные плюсы, так как следующий кадр рисуется СРАЗУ после окончания рендера текущего, а не выжидается определенное время (длительность одного кадра таймлайна например). из этого следует:
во-первых: при малой загруженности перерисовкой stage повышается очень заметно фреймрейт.
во-вторых: если юзать ENTER_FRAME, то достаточно системе не успеть дорисовать кадр хотя бы на 1%, как кадр будет пропущен (тоесть сразу локально фреймрейт упадет вдвое). с таймером же мы сами назначаем, когда нам закончить ЭТОТ кадр и перейти к следующему

serenkiy · 03.04.2009, 00:25

Предлагаю Вам сделать счетчик FPS и судить по нему, и, в зависимости от некоторых эталонных показателей, включать/отключать определенные графические "фишки".
Тем самым можно использовать метод самоподгонки, разберу на примере:
Пользователь запустил Ваш проект на максимальных настройках. Допустим, первые 10 секунд машина тестируется на FPS (мин. и макс. значения). На базе этого анализа, автоматически решается, стоит ли воспроизводить те или иные эффекты (например, возьмем 3Д движок - динамические тени сильно виляют на производительность). Объявляем булевские переменные (Shadows:Boolean, Lighting:Boolean...), и исходя из анализов они равны true или false. А сам рендер при отрисовке сцены посмотрит на эти булевские значения и решит, что ему отрисовывать.

Dimonte · 03.04.2009, 00:52

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

Далее, про таймеры. Я не совсем согласен с kirea, не так страшен ENTER_FRAME, но таймеры все-таки лучше. Просто так свинченный таймер не даст никаких заметных прибавок в плавности процесса, может даже хуже сделать. Я уже давно и успешно пользуюсь вот этой реализацией таймера - http://www.8bitrocket.com/newsdispla...newspage=10248. Тут код создан для игр, и прекрасно в них работает, проверено на собственном опыте. Суть кода, если вкратце: цикл кадра считает, сколько он занял времени, и подстраивает таймер под этот результат. Если кадры все посчитать не получается, кадр или пропускается, или можно написать свою функцию для, к примеру, обсчета физики без рисования графики. С этим же циклом можно считать отношение пропущенных кадров к отрисованным и подстраивать качество на ходу.

litebox · 03.04.2009, 11:47

Да, определять мощность ПК через FPS идея хорошая, у меня как раз такой счетчик уже есть. Что касается таймера, на этот сайт уже попадал, но как то лень было на инглише читать, теперь, думаю, пора