2011-09-14 16 views
5

que tienen esta línea de código:Java: openGL: JOGL: ¿Qué sucede detrás de las escenas cuando llamo al método display()?

renderableObject.renderObject(gl, glu); 

Esto conduce a una larga lista de objetos que están siendo prestados por OpenGL, sin embargo, sólo funciona cuando se utiliza de la siguiente manera:

@Override 
public void display(GLAutoDrawable drawable) 
    {    
     renderableObject.renderObject(gl, glu); 
    } 

Si llamo a la línea fuera del método de visualización anulado recibo una excepción que dice que no hay glContext en el hilo actual, de hecho si llamo a cualquier comando gl draw fuera de este método recibo la misma excepción

ahora idealmente quiero crear una gran cantidad de listas de visualización s una vez, luego renderícelos en cada cuadro con la lista de visualización impar para recrear periódicamente. Sin embargo, tengo que pasar por este único método de visualización(), lo que significa que tendría que probar cada cuadro si la lista de visualización se ha creado, o si necesita cambios, etc. ¡60 veces por segundo! Qué desperdicio de poder de procesamiento cuando podría manejarlos por separado una vez cuando sea necesario.

Así que, sea lo que sea que llame al método display(), me gustaría poder replicarlo, permitiéndome crear una gran cantidad de mis propios métodos de visualización personalizados, ¡sin tener que recurrir a este único método para todo!

Entonces, ¿hay una simple llamada gl que puedo hacer?

Respuesta

2

Por extraño que parezca, esta es la forma en que se supone que funciona.

Detrás de escena, lo que sucede es que cuando las GLCanvas que has creado se dibujan, detrás de las escenas JOGL está haciendo un montón de trabajo. Está creando un GLContext y actualizándolo para el GLCanvas para el hilo actual. Solo cuando se hace eso, puedes hacer llamadas de renderizado. Un GLContexto que no se haya actualizado, o un objeto GL que se derive de él, no le sirve. Además, el GLContext se hace actual solo para esa cadena, y se convierte en no actual tan pronto como finalice la llamada de pantalla, por lo tanto, no podrá trabajar si se hace referencia a ella o al GL para su uso posterior.

Casi todas las aplicaciones JOGL funcionan de esa manera. Usted crea un GLEventListener e implementa display() en él, extrae un GL del GLAutoDrawable y lo usa para hacer llamadas de renderizado. No desea realizar llamadas de representación en otro lugar, más de lo que desea hacer llamadas de Graphics2D fuera del método paint(). La mayoría de los programadores principiantes de Java intentan pintar desde fuera del método de pintura; esto es similar Si necesita desencadenar un repintado, hágalo de la misma forma que lo haría con Java2D: use invalidate(). (Por supuesto, puede escribir submétodos que se invocan desde el método display() y que toman el GL o GLAutoDrawable como argumento).

Existen formas de crear específicamente un GLContext y hacerlo actual, pero rara vez son necesarias. Casi siempre es mejor usar el enfoque aquí.

+1

detrás de escena JOGL está haciendo un montón de trabajo. Está creando un GLContext y actualizándolo para el GLCanvas para el hilo actual. ------- ¿No podría hacer esto yo mismo? – Troyseph

+0

Sebastian Troy, tu puedes pero lo que hace no es realmente trivial. Puedes hacer las operaciones mínimas estrictas (obtener el GLContext de GLAutoDrawable y hacerlo actual), pero ten en cuenta que JOGL contiene montones de bonitos caprichos y soluciones que lo hacen mucho más seguro que el OpenGL nativo en C o con otro enlace en Java. C#, Python, ... Además, es realmente fácil arruinar tu rendimiento si haces algo malo. Cuando porté Ardor3D a JOGL 2, descubrí que makeCurrent() se llamó inútilmente una vez, eliminar esta llamada me dio un gran impulso cuando v-sync estaba desactivado. – gouessej

Cuestiones relacionadas