Java: wait () ограничивает частоту кадров до 64 - PullRequest
Новая
       26

Java: wait () ограничивает частоту кадров до 64

1 голос
/ 29 февраля 2012

У меня есть это в моем коде в основном цикле (2D-игра в окне): 

try{
  synchronized(this){

    wait(3);
  }
}
catch(Exception ex) {
  System.out.println(ex);
}

Этот фрагмент кода заставляет FPS ограничить 64, и я не знаю почему.Я не использую другие синхронизированные блоки.Забавно, что когда веб-браузер открыт, fps больше не ограничен.Может кто-нибудь сказать мне, как избавиться от этого ограничения в 64 кадра в секунду?Мне не удалось найти другие темы с этой проблемой.

РЕДАКТИРОВАТЬ:

  • Без ожидания (3);- 180 кадров в секунду.
  • При ожидании (3) и открытом браузере (Opera) - ~ 113 к / с.
  • С ожиданием (3) и без браузера - 64 кадра в секунду.

Как браузер может изменять fps?

Ответы [ 3 ]

5 голосов
/ 29 февраля 2012

Хотя разрешение параметров wait и sleep указано в миллисекундах, вы почти наверняка никогда не получите именно ту задержку, которую вы запрашиваете.

В системе Windows разрешение составляет приблизительно 15 мс, что дает 1000/15 = 66 к / с

2 голосов
/ 29 февраля 2012

Если вы не используете какие-либо другие синхронизированные блоки, значит, нет никого, кто бы мог notify() ваш поток. Это означает, что вы, вероятно, говорите, что ваше приложение должно спать не менее 3 миллисекунд на каждой итерации. Кроме того, вы можете потерять еще немного времени из-за того, что поток отдает свой квант времени при переходе в спящий режим, а разрешение часов также обычно превышает 1 мс, в зависимости от ОС.

64 FPS означает, что кадр занимает чуть более 15 мс. Скажите нам, каков ваш «незакрытый» FPS, подсчитайте, сколько мс на кадр он переводит, и посмотрите, в чем разница. Если разница во времени кадра без потерянного кода составляет порядка 3-10 мс (10 мс, вероятно, является разумным верхним пределом гранулярности тактовой частоты в нормальной системе), это, вероятно, является только результатом wait() , Если без wait() ваши кадры занимают всего 1 мс, возможно, есть некоторый дополнительный эффект.

РЕДАКТИРОВАТЬ после комментария Яна : 115 FPS означает 8,7 мс на кадр. Переход от этого к 15 из-за wait(3) кажется вероятным. Я не уверен, как запуск другого приложения в фоновом режиме может повлиять на это. Возможно, наличие другой задачи в фоновом режиме влияет на поведение планировщика. Приносит ли другая задача FPS обратно к 115 или к некоторому промежуточному значению?

РЕДАКТИРОВАТЬ после второго комментария Яна : если 180 вместо 115, у нас 5,5 мс на кадр. Это увеличивает разницу, но поскольку часы Windows довольно грубые (как указывали другие), это все еще в пределах эффекта, описанного выше.

0 голосов
/ 29 февраля 2012

Не пытайтесь получить более 60 кадров в секунду.Современный дисплей не будет отображать более 60 кадров в секунду.

...