Re: [sdljava-users] Usage example for glGetDoublev
Status: Beta
Brought to you by:
ivan_ganza
From: Gregor <Gre...@gm...> - 2005-09-11 10:37:20
|
Hi! My problem is that I really have to allocate these direct buffers on demand= =20 for something like one or two opengl calls each. Furthermore, they really a= re=20 quite small. The biggest buffer I use that way is there to store a matrix o= f=20 4x4 doubles, that is, 128 bytes. Using byte buffers may be a valid approach when working on large, uniform=20 amounts of data like framebuffers. But that is not the case with geometry=20 data for OpenGL. Using vertex arrays is almost out of question for me since= =20 the geometry data I have is very dynamic in every way. Well, this is not trying to be a rant. I'm just not yet convinced that this= is=20 the right approach. It looks like far too much overhead to me, making all t= he=20 OpenGL functions taking (small) arrays practically useless. Maybe some=20 benchmarking is in order to get some definitive answers, but I don't have=20 enough time for that. Regards, Gregor On Saturday 10 September 2005 23:39, Ivan Z. Ganza wrote: > Hi Gregor, > > The direct buffers introduced with NIO are better than sliced > bread...:-) Without them I don't think it would be possible to achieve > any level of meaningfully performance. > > A direct buffer is mapped directly to a region of memory inside the > JVM's memory space. When you perform operations on a direct buffer they > effect the memory directly and thus and are very fast. The other option > is to copy the data each time from the JVM's memory space into the > native code space (or visa versa). The copy method is an order of > magnitude slower. First the new array must be allocated. Then the data > must be copied into the array each time. > > For an idea of the speed difference look at the difference in execution > time between updating the screen using the two methods: > > ByteBuffer getPixelData() > > and > > public void setPixelData32(int[] pixelData) > > > If you are using these direct buffers you should allocate all the > buffers you need before doing anything. Then utilize them later however > you wish. Otherwise the performance will be much worse if a new one is > constantly created. Notice that getPixelData() only creates the buffer > once. The buffer directly has access to the data of the surface! > > -Ivan/ > > Gregor M=FCckl wrote: > >Hi, Ivan! > > > >Thanks for your help. Indeed, ByteBuffer.allocateDirect() is the right > >solution and it seems to work now. I cannot tell for sure yet as the > >gtk-based input handling is still not working properly and I therefore > > can't navigate the 3D view. > > > >However, I feel that relyinig on java.nio.ByteBuffer and derivates is a > > bit strange, especially given their somewhat peculiar design. Looking at > > the code I have now which has to copy data to newly created buffers eve= ry > > time I need to pass an array to OpenGL, I get the feeling that this > > slower than dealing directly with arrays, which are readiy available in > > my case and probably more optimizeable by the Java compiler and JVM. > > > >What was the reason for using these buffers instead of arrays? Am I > > missing something here? > > > >Regards, > >Gregor > > > >On Saturday 10 September 2005 01:37, Ivan Z. Ganza wrote: > >>Gregor, > >> > >>I had a look in the code and intact SDLSurface isn't a good example > >>because the buffer is created in the native code. Have a look at > >>ByteBufferPool instead. > >> > >>-Ivan/ > >> > >>Gregor M=FCckl wrote: > >>>Hi! > >>> > >>>I"m trying to use glGetDoublev to read back the modelview and projecti= on > >>>matrices from OpenGL. However, it looks like I'm doing something wrong > >>>with the DoubleBuffers required for that. > >>> > >>>What I'm doing basically is in this code: > >>> > >>> GlewImpl gl; > >>> private ml.math.Matrix4 modelViewMatrix; > >>> private ml.math.Matrix4 projectionMatrix; > >>> private double viewFieldOfView; > >>> private DoubleBuffer matrixBuffer; > >>> > >>> public ViewWindowSpace(Widget parent) > >>> { > >>> super(); > >>> > >>> matrixBuffer=3DDoubleBuffer.allocate(16); > >>> modelViewMatrix=3Dnew Matrix4(); > >>> projectionMatrix=3Dnew Matrix4(); > >>> > >>> currentRenderMode=3DRenderMode.Solid; > >>> > >>> initGLContext(); > >>> > >>> // snip: unrelated code > >>> > >>> addListener(new LifeCycleListener() { > >>> > >>> public void lifeCycleEvent(LifeCycleEvent e) > >>> { > >>> // TODO Auto-generated method stub > >>> if(e.getType()=3D=3DLifeCycleEvent.Type.REALIZE) { > >>> setupViewingAreaInitial(); > >>> } > >>> > >>> } > >>> } > >>> > >>> // snip: unrelated code > >>> } > >>> > >>> protected void setupViewingAreaInitial() > >>> { > >>> viewFieldOfView=3D45.0; > >>> > >>> glBegin(); > >>> GlewJNI.SWIG_glew_init(); > >>> gl=3Dnew GlewImpl(); > >>> int width =3D getWidth(); > >>> int height =3D getHeight(); > >>> gl.glViewport(0, 0, width, height); > >>> gl.glMatrixMode(GL.GL_PROJECTION); // select the projection > >>>matrix > >>> gl.glLoadIdentity(); // reset the > >>>projection matrix > >>> float fAspect =3D (float) width / (float) height; > >>> gl.gluPerspective(viewFieldOfView, fAspect, 0.5f, 400.0f); > >>> gl.glMatrixMode(GL.GL_MODELVIEW); // select the modelview > >>>matrix gl.glLoadIdentity(); > >>> > >>> gl.glGetDoublev(GL.GL_MODELVIEW_MATRIX,matrixBuffer); > >>> modelViewMatrix.setFromOpenGLMatrix(matrixBuffer); > >>> gl.glGetDoublev(GL.GL_PROJECTION_MATRIX,matrixBuffer); > >>> projectionMatrix.setFromOpenGLMatrix(matrixBuffer); > >>> > >>> glEnd(); > >>> } > >>> > >>>What this does: > >>> > >>>The constructor allocates the DoubleBuffer in question and registers an > >>>event handler to do the rest of the initialilsation once the opengl > >>>context can actually be used. When this is the case, > >>>setupViewingAreaInitial is called to perform the init of the gl contex= t. > >>>This fails with a NullPointerException in the first call to > >>>gl.glGetDoublev(). The console output for this exception is as follows: > >>> > >>>Exception in thread "main" java.lang.NullPointerException: null address > >>>returned from GetDirectBufferAddress() call. Make sure the buffer is a > >>>_direct_ buffer. > >>> at org.gljava.opengl.x.swig.GlewJNI.glGetDoublev(Native Method) > >>> at org.gljava.opengl.impl.glew.GlewImpl.glGetDoublev(GlewImpl.java:14= 3) > >>> at > >>>ml.ui.plugins.view.ViewWindowSpace.setupViewingAreaInitial(ViewWindowS= pa > >>>ce .java:322) at > >>>ml.ui.plugins.view.ViewWindowSpace$2.lifeCycleEvent(ViewWindowSpace.ja= va > >>>:2 77) at org.gnu.gtk.Widget.fireLifeCycleEvent(Widget.java:735) > >>> at org.gnu.gtk.Widget.handleRealize(Widget.java:764) > >>> at org.gnu.gtk.Widget.gtk_widget_show(Native Method) > >>> at org.gnu.gtk.Widget.show(Widget.java:119) > >>> at ml.core.State.createMainWindow(State.java:158) > >>> at ml.ML3D.<init>(ML3D.java:49) > >>> at ml.ML3D.main(ML3D.java:66) > >>> > >>>I have no clue why this happens. Do I initialize the DoubleBuffer in > >>>question badly? Is there any example that shows how it should be done? > >>>Any help would be appreciated. > >>> > >>>Regards, > >>>Gregor > >>> > >>> > >>>------------------------------------------------------- > >>>SF.Net email is Sponsored by the Better Software Conference & EXPO > >>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle > >>>Practices Agile & Plan-Driven Development * Managing Projects & Teams * > >>>Testing & QA Security * Process Improvement & Measurement * > >>>http://www.sqe.com/bsce5sf > >>>_______________________________________________ > >>>sdljava-users mailing list > >>>sdl...@li... > >>>https://lists.sourceforge.net/lists/listinfo/sdljava-users > >> > >>------------------------------------------------------- > >>SF.Net email is Sponsored by the Better Software Conference & EXPO > >>September 19-22, 2005 * San Francisco, CA * Development Lifecycle > >> Practices Agile & Plan-Driven Development * Managing Projects & Teams * > >> Testing & QA Security * Process Improvement & Measurement * > >> http://www.sqe.com/bsce5sf > >> _______________________________________________ > >>sdljava-users mailing list > >>sdl...@li... > >>https://lists.sourceforge.net/lists/listinfo/sdljava-users > > > >------------------------------------------------------- > >SF.Net email is Sponsored by the Better Software Conference & EXPO > >September 19-22, 2005 * San Francisco, CA * Development Lifecycle > > Practices Agile & Plan-Driven Development * Managing Projects & Teams * > > Testing & QA Security * Process Improvement & Measurement * > > http://www.sqe.com/bsce5sf > > _______________________________________________ > >sdljava-users mailing list > >sdl...@li... > >https://lists.sourceforge.net/lists/listinfo/sdljava-users > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic= es > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > sdljava-users mailing list > sdl...@li... > https://lists.sourceforge.net/lists/listinfo/sdljava-users |