자바 : (기다릴)는 메인 루프에서 내 코드 (창에서 2D 게임)에서 나는이가 64

Question

에 FPS를 제한 :

try{ 
    synchronized(this){ 

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

이 코드 조각 (64)에 모자를 씌우는 FPS에 원인이

및 나는 이유를 모른다. 다른 동기화 된 블록을 사용하지 않습니다. 유쾌하게도 웹 브라우저가 열리면 fps에 더 이상 표시되지 않습니다. 아무도 64fps 제한을 없애는 방법을 말해 줄 수 있습니까? 이 문제로 다른 주제를 찾지 못했습니다.

EDIT :

• 대기하지 않고 (3); - 180fps.
• 기다림 (3)과 브라우저 (Opera)가 열린 상태에서 ~ 113fps.
• 대기 모드 (3) 및 브라우저 없음 - 64fps.

브라우저가 fps를 어떻게 바꿀 수 있습니까?

Answer 1

wait 및 sleep의 매개 변수의 해상도는 밀리 초 단위이지만 요청하는 지연을 정확히 알 수는 없습니다. Windows 시스템 해상도에

는 15분의 1,000 = 66fps

Answer 2

60fps를 넘지 마십시오. 현대 디스플레이는 60fps 이상을 표시하지 않습니다.

Answer 3

당신이 다른 동기화 블록을 사용하지 않는 경우, 다음 스레드를 notify() 할 일이 없기를주는 약 15ms의입니다. 즉, 앱을 반복 할 때마다 최소 3 밀리 초 동안 잠자기 상태로 있다고 앱을 알리는 것입니다. 또한 스레드가 잠자기 상태가 될 때 시간 퀀텀을 포기하고 OS에 따라 시계 해상도가 일반적으로 1ms 이상이기 때문에 시간이 더 많이 걸릴 수 있습니다.

64 FPS는 프레임이 15ms보다 약간 더 걸린다는 것을 의미합니다. "uncapped"FPS가 무엇인지 말해 주시고, 프레임 당 얼마나 많은 ms를 계산하여 그 차이가 무엇인지 확인하십시오. 손실 된 코드가없는 프레임 시간의 차이가 3-10ms (10ms는 아마도 정상 시스템의 클록 세분성에 대한 합리적인 상한 임) 인 경우 이는 아마도 wait()의 결과 일뿐입니다. 프레임이 wait()없이 1ms 밖에 걸리지 않으면 추가 효과가있을 수 있습니다.

Jan 's comments 이후 EDIT : 115FPS는 프레임 당 8.7ms를 의미합니다. wait(3) 때문에 15 개로 갈 가능성이 있습니다. 백그라운드에서 다른 앱을 실행하면 어떻게 영향을 미칠지 잘 모르겠습니다. 아마도 백그라운드에서 다른 작업을하는 것은 스케줄러의 동작에 영향을 미칩니다. 다른 작업이 FPS를 115 또는 중간 값으로 되 돌리십니까?

01 월 두 번째 설명 후 편집 : 115 대신 180 일 경우 프레임 당 5.5 밀리 초가됩니다. 차이가 커지지 만 Windows 클록이 다소 거칠기 때문에 (위에서 지적한 것처럼) 이는 위에서 설명한 효과의 한도 내에 있습니다.