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
|