JDK-4237283 : Need a way to synchronize with the vertical refresh cycle of the framebuffer
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.2.1
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 1999-05-11
  • Updated: 2018-09-05
Related Reports
Relates :  
JDK-4123961 - (hpi) Need higher resolution System.currentTimeMillis on Win32
Description

Name: krT82822			Date: 05/11/99


Today there is no good way of locking the framerate. This is because all the possible ways
of locking the update rate of an animation depends on System.currentTimeMillis() wich is
not working properly on NT and Win95. (See bugreport 4236825)

There should really be a way to lock the framerate or synchronize with the raster beam
or something....  otherwise the Java 2 platform is useless for multimedia programming!!!!

Best Regards
/John Eriksson
(Review ID: 58054) 
======================================================================
Comments
EVALUATION There is already another bug submitted against the granularity of the system clock (4123961). Since the system timer is not a 2D API issue, I have rewritten the synopsis to address just the vertical refresh synchronization which does fall under the 2D API. jim.graham@Eng 1999-05-11
11-05-1999
WORK AROUND Animation loops can be written to more accurately estimate the current real time as a function of the current return value of currentTimeMillis() and a measurement of average frame drawing rate calculated over a longer period of time designed to minimize the granularity of the system clock. The estimate would need to synch with the system timer using some sort of fuzzy comparison that takes into account a measurement of the granularity of the clock. jim.graham@Eng 1999-05-11
11-05-1999