Esto puede ser una continuación de this question, donde sugerí que tener un ciclo de redibujado que simplemente seguía dibujando una y otra vez podría ser un poco excesivo. Puede haber una API para averiguar las capacidades de la pantalla de los dispositivos, pero si la hay no la conozco. Cuando está escribiendo su propia función de bucle/secuencia de eventos, puede controlar la velocidad de fotogramas por la frecuencia con la que llama a su método de "dibujado". Normalmente, creo que para la mayoría de los propósitos, estarías bien con una frecuencia de actualización de 30 o más. Si estás escribiendo un juego de acción rápida, que necesita animación rápida, entonces puede querer correr lo más rápido que puedas, mientras más fps, más suave será.
Un bucle de eventos típica (función de ejecución de rosca) podría ser algo como esto:
// define the target fps
private static final int UPDATE_RATE = 30; // Frames per second (fps)
public void run() {
while(running) { // volatile flag, set somewhere else to shutdown
long beginTimeMillis, timeTakenMillis, timeLeftMillis;
// get the time before updates/draw
beginTimeMillis = System.currentTimeMillis();
// do the thread processing/draw
performUpdates(); // move things if required
draw(); // draw them on the screen
// get the time after processing and calculate the difference
timeTakenMillis = System.currentTimeMillis() - beginTimeMillis;
// check how long there is until we reach the desired refresh rate
timeLeftMillis = (1000L/UPDATE_RATE) - timeTakenMillis;
// set some kind of minimum to prevent spinning
if (timeLeftMillis < 5) {
timeLeftMillis = 5; // Set a minimum
}
// sleep until the end of the current frame
try {
TimeUnit.MILLISECONDS.sleep(timeLeftMillis);
} catch (InterruptedException ie) {
}
}
}
¿Estamos hablando de una superficie GL, o en general (como cuando se usa una animación)? No hay una tasa de fotogramas predeterminada, puedo decir eso por adelantado. – EboMike
¡Solo para decir animación 2D! usando vistas de superficie – m4n07