sdljava-users — General Discussion about sdljava and gljava

[sdljava-users] VM Crash while rendering text via TTF

[Patric R. <pa...@ma...>]

Hello List,

I am currently having some problems with the rendering of text. The 
Program renders some text every second. At the beginning the program 
works well, but after approx. 3-5 minutes the program terminates and 
outputs a thread dump.

It seems to be a sdljava bug. Maybe somebody knows the reason and can 
help me.

Best Regards,
Patric

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x778ccaad, pid=1864, 
tid=2044
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode)
# Problematic frame:
# C  [ntdll.dll+0x4caad]
#

Stack: [0x24450000,0x24490000),  sp=0x2448f780,  free space=253k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, 
C=native code)
C  [ntdll.dll+0x4caad]
C  [MSVCRT.dll+0x1532]
C  [MSVCRT.dll+0x14cf]
C  [SDLJava_ttf.dll+0x1a9d]
J 
sdljava.x.swig.SWIG_SDLTTFJNI.TTF_RenderText_Solid_FAST(JLjava/lang/String;SSS)J
J 
sdljava.x.swig.SWIG_SDLTTF.TTF_RenderText_Solid_FAST(Lsdljava/x/swig/SWIGTYPE_p__TTF_Font;Ljava/lang/String;SSS)Lsdljava/x/swig/SDL_Surface;

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 
sdljava.x.swig.SWIG_SDLTTFJNI.TTF_RenderText_Solid_FAST(JLjava/lang/String;SSS)J
J 
sdljava.x.swig.SWIG_SDLTTF.TTF_RenderText_Solid_FAST(Lsdljava/x/swig/SWIGTYPE_p__TTF_Font;Ljava/lang/String;SSS)Lsdljava/x/swig/SDL_Surface;

Re: [sdljava-users] EventManager: using pollEvent() instead of waitEvent() ?

[Patric R. <pa...@ma...>]

It isn't a real problem. SDL_WaitEvent() has to use a loop, too.

As you can see in the source:

int SDL_WaitEvent (SDL_Event *event)
{
	while ( 1 ) {
		SDL_PumpEvents();
		switch(SDL_PeepEvents(event, 1, SDL_GETEVENT, SDL_ALLEVENTS)) {
		    case -1: return 0;
		    case 1: return 1;
		    case 0: SDL_Delay(10);
		}
	}
}

I think, it would be best to maintain the original timings and sleep for 
10 ms.

Patric



Ivan Z. Ganza schrieb:
> Yes it sounds like pollEvent() would be better here.  The only problem
> is that it will eat much or all of the CPU in the loop unless we sleep
> some between calls.  Perhaps a configurable param?
> 
> -Ivan/
> 
> Patric Rufflar wrote:
> 
> 
>>Hello List,
>>
>>I am currently having problems stopping the EventManager thread in
>>some cases. It seems that the native call to waitEvent() cannot be
>>interrupted by calling interrupt() of the thread.
>>
>>I think using pollEvent() would be better here (because it is already
>>an own thread) and will fix some problems.
>>
>>What do you think about it?
>>
>>Best Regards
>>Patric
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by:
>>Power Architecture Resource Center: Free content, downloads, discussions,
>>and more. http://solutions.newsforge.com/ibmarch.tmpl
>>_______________________________________________
>>sdljava-users mailing list
>>sdl...@li...
>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users
> 
> 

Re: [sdljava-users] EventManager: using pollEvent() instead of waitEvent() ?

[Ivan Z. G. <iva...@ya...>]

Yes it sounds like pollEvent() would be better here.  The only problem
is that it will eat much or all of the CPU in the loop unless we sleep
some between calls.  Perhaps a configurable param?

-Ivan/

Patric Rufflar wrote:

> Hello List,
>
> I am currently having problems stopping the EventManager thread in
> some cases. It seems that the native call to waitEvent() cannot be
> interrupted by calling interrupt() of the thread.
>
> I think using pollEvent() would be better here (because it is already
> an own thread) and will fix some problems.
>
> What do you think about it?
>
> Best Regards
> Patric
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users

Re: [sdljava-users] Using multiple contexts with gljava

[Ivan Z. G. <iva...@ya...>]

Hmm,

Its a good point.  There is nothing infact that is making gljava depend
on sdljava at the level of code.  However, having said that, currently,
you cannot obtain a GL context in any way except via the setVideoMode()
call.   Nothing is stopping someone from initializing an opengl context
on their own and then using it via gljava.

I will look into this in more detail.  I wasn't aware that 1.3 had that
capability.

-Ivan/

Gregor M=FCckl wrote:

>Hi!
>
>It is unfortunate that you have such a view on gljava considering your=20
>earliser statement that gljava should be useable without sdljava. And in=
 that=20
>casse it is well possible to add multiple contexts.
>
>And as far as I know SDL 1.3 already has support for multiple contexts, =
but=20
>not necessarily multiple SDL windows (these are not the same, mind you!).
>
>Regards,
>Gregor
>
>On Sunday 16 October 2005 16:38, Ivan Z. Ganza wrote:
> =20
>
>>Unfortunately I don't think this is currently possible.  The reason is
>>that SDL only supports one window currently.  SDL 2.0 I belive is
>>supposed to add multi-window capability.
>>
>>Right now the GL context is initialized and created by the SDL layer
>>when setVideoMode() is called with the SDL_OPENGL flag set.  sdljava
>>doesn't create the contexts on its own.
>>
>>I really wish we could have multiple windows but I don't see how its
>>currently possible...
>>
>>-Ivan/
>>
>>Gregor M=FCckl wrote:
>>   =20
>>
>>>Hi!
>>>
>>>Using multiple contexts with gljava not really possible at the moment =
as
>>>the underlying GLEW needs to be informed about context changes (provid=
ed,
>>>it is compiled with support for context changes in the first place), b=
ut
>>>that function is not exported yet. However, I'll need it soon because =
I
>>>need more than one context in Moonlight|3D in the future.
>>>
>>>Could you please look into this matter? It's explained quite well on t=
he
>>>GLEW homepage.
>>>
>>>Regards,
>>>Gregor
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by:
>>>Power Architecture Resource Center: Free content, downloads, discussio=
ns,
>>>and more. http://solutions.newsforge.com/ibmarch.tmpl
>>>_______________________________________________
>>>sdljava-users mailing list
>>>sdl...@li...
>>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>>     =20
>>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by:
>>Power Architecture Resource Center: Free content, downloads, discussion=
s,
>>and more. http://solutions.newsforge.com/ibmarch.tmpl
>>_______________________________________________
>>sdljava-users mailing list
>>sdl...@li...
>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>   =20
>>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Power Architecture Resource Center: Free content, downloads, discussions=
,
>and more. http://solutions.newsforge.com/ibmarch.tmpl
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
> =20
>

Re: [sdljava-users] Using multiple contexts with gljava

[Gregor <Gre...@gm...>]

Hi!

It is unfortunate that you have such a view on gljava considering your=20
earliser statement that gljava should be useable without sdljava. And in th=
at=20
casse it is well possible to add multiple contexts.

And as far as I know SDL 1.3 already has support for multiple contexts, but=
=20
not necessarily multiple SDL windows (these are not the same, mind you!).

Regards,
Gregor

On Sunday 16 October 2005 16:38, Ivan Z. Ganza wrote:
> Unfortunately I don't think this is currently possible.  The reason is
> that SDL only supports one window currently.  SDL 2.0 I belive is
> supposed to add multi-window capability.
>
> Right now the GL context is initialized and created by the SDL layer
> when setVideoMode() is called with the SDL_OPENGL flag set.  sdljava
> doesn't create the contexts on its own.
>
> I really wish we could have multiple windows but I don't see how its
> currently possible...
>
> -Ivan/
>
> Gregor M=FCckl wrote:
> >Hi!
> >
> >Using multiple contexts with gljava not really possible at the moment as
> > the underlying GLEW needs to be informed about context changes (provide=
d,
> > it is compiled with support for context changes in the first place), but
> > that function is not exported yet. However, I'll need it soon because I
> > need more than one context in Moonlight|3D in the future.
> >
> >Could you please look into this matter? It's explained quite well on the
> > GLEW homepage.
> >
> >Regards,
> >Gregor
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by:
> >Power Architecture Resource Center: Free content, downloads, discussions,
> >and more. http://solutions.newsforge.com/ibmarch.tmpl
> >_______________________________________________
> >sdljava-users mailing list
> >sdl...@li...
> >https://lists.sourceforge.net/lists/listinfo/sdljava-users
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users

[sdljava-users] EventManager: using pollEvent() instead of waitEvent() ?

[Patric R. <pa...@ma...>]

Hello List,

I am currently having problems stopping the EventManager thread in some 
cases. It seems that the native call to waitEvent() cannot be 
interrupted by calling interrupt() of the thread.

I think using pollEvent() would be better here (because it is already an 
own thread) and will fix some problems.

What do you think about it?

Best Regards
Patric

[sdljava-users] need help to test gljava dlls on windows

[Ivan Z. G. <iva...@ya...>]

Greetings,

I've been working on a release for a while.  I've been able to build all
the DLLs and all is working perfectly except for the gljava dll.  For
some reason the VM is crashing and the method its dying on is
SWIG_glew_init() -- see below.

Its really weird because when I copy over the OLD gljlava.dll from the
previous release all is fine.  I'm wordering if someone can build the
gljava dlls from the latest code and see if they work for them.

If I could resolve this issue then I can make a new release.

Appreciate any help,
-Ivan/





-----------------------

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7c901095, pid=1520,
tid=1596
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_09-b05 mixed mode)
# Problematic frame:
# C  [ntdll.dll+0x1095]
#

---------------  T H R E A D  ---------------

Current thread (0x00035db0):  JavaThread "main" [_thread_in_native, id=1596]

siginfo: ExceptionCode=0xc0000005, writing address 0x03f1f128

Registers:
EAX=0xffffffff, EBX=0x1414cf98, ECX=0x00000000, EDX=0x03f1f124
ESP=0x0007f97c, EBP=0x0007f988, ESI=0x03f1f104, EDI=0x00035db0
EIP=0x7c901095, EFLAGS=0x00000216

Top of Stack: (sp=0x0007f97c)
0x0007f97c:   5ed03e70 77c3b90d 03f1f124 0007f9c4
0x0007f98c:   77c40e2b 03f1f104 00035db0 1414cfe0
0x0007f99c:   1414cf98 000abeb8 03f1f104 5ed1c3d5
0x0007f9ac:   0007f994 0007f5a0 0007fbb4 77c35c94
0x0007f9bc:   77c14610 ffffffff 0007f9dc 03f11055
0x0007f9cc:   03f1f104 03f2a01c 03f5e04c 00000000
0x0007f9dc:   0007f9f0 03f11078 00000000 00000000
0x0007f9ec:   0007fa1c 0007fa1c 00a781a6 00035e4c

Instructions: (pc=0x7c901095)
0x7c901085:   00 00 00 ff 72 14 b8 ff ff ff ff b9 00 00 00 00
0x7c901095:   f0 0f b1 4a 04 75 1c 83 c4 04 64 8b 0d 18 00 00


Stack: [0x00040000,0x00080000),  sp=0x0007f97c,  free space=254k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
C=native code)
C  [ntdll.dll+0x1095]
C  [MSVCRT.dll+0x30e2b]
C  [gljava.dll+0x1055]
C  [gljava.dll+0x1078]
j  org.gljava.opengl.x.swig.GlewJNI.SWIG_glew_init()J+0
j  sdljava.video.SDLVideo.setVideoMode(IIIJ)Lsdljava/video/SDLSurface;+44
j  sdljava.example.spaceinvaders.SpaceInvaders.initDisplay()V+17
j  sdljava.example.spaceinvaders.SpaceInvaders.init()V+1
j  sdljava.example.spaceinvaders.SpaceInvaders.main([Ljava/lang/String;)V+12
v  ~StubRoutines::call_stub
V  [jvm.dll+0x71bdf]
V  [jvm.dll+0xabac2]
V  [jvm.dll+0x71aec]
V  [jvm.dll+0x778e9]
V  [jvm.dll+0x7854e]
C  [java.exe+0x14bf]
C  [java.exe+0x624d]
C  [kernel32.dll+0x16d4f]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.gljava.opengl.x.swig.GlewJNI.SWIG_glew_init()J+0
j  sdljava.video.SDLVideo.setVideoMode(IIIJ)Lsdljava/video/SDLSurface;+44
j  sdljava.example.spaceinvaders.SpaceInvaders.initDisplay()V+17
j  sdljava.example.spaceinvaders.SpaceInvaders.init()V+1
j  sdljava.example.spaceinvaders.SpaceInvaders.main([Ljava/lang/String;)V+12
v  ~StubRoutines::call_stub

---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
  0x009bbcf0 JavaThread "CompilerThread0" daemon [_thread_blocked, id=468]
  0x009bb080 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=508]
  0x009b8580 JavaThread "Finalizer" daemon [_thread_blocked, id=288]
  0x009b71f8 JavaThread "Reference Handler" daemon [_thread_blocked, id=216]
=>0x00035db0 JavaThread "main" [_thread_in_native, id=1596]

Other Threads:
  0x009f76d0 VMThread [id=1616]
  0x009f89e8 WatcherThread [id=2208]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
 def new generation   total 576K, used 467K [0x10010000, 0x100b0000,
0x104f0000)
  eden space 512K,  91% used [0x10010000, 0x10084e38, 0x10090000)
  from space 64K,   0% used [0x10090000, 0x10090000, 0x100a0000)
  to   space 64K,   0% used [0x100a0000, 0x100a0000, 0x100b0000)
 tenured generation   total 1408K, used 0K [0x104f0000, 0x10650000,
0x14010000)
   the space 1408K,   0% used [0x104f0000, 0x104f0000, 0x104f0200,
0x10650000)
 compacting perm gen  total 4096K, used 1298K [0x14010000, 0x14410000,
0x18010000)
   the space 4096K,  31% used [0x14010000, 0x14154b50, 0x14154c00,
0x14410000)

Dynamic libraries:
0x00400000 - 0x0040b000     C:\WINDOWS\system32\java.exe
0x7c900000 - 0x7c9b0000     C:\WINDOWS\system32\ntdll.dll
0x7c800000 - 0x7c8f4000     C:\WINDOWS\system32\kernel32.dll
0x77dd0000 - 0x77e6b000     C:\WINDOWS\system32\ADVAPI32.dll
0x77e70000 - 0x77f01000     C:\WINDOWS\system32\RPCRT4.dll
0x77c10000 - 0x77c68000     C:\WINDOWS\system32\MSVCRT.dll
0x08000000 - 0x0813d000     C:\Program
Files\Java\j2re1.4.2_09\bin\client\jvm.dll
0x77d40000 - 0x77dd0000     C:\WINDOWS\system32\USER32.dll
0x77f10000 - 0x77f56000     C:\WINDOWS\system32\GDI32.dll
0x76b40000 - 0x76b6d000     C:\WINDOWS\system32\WINMM.dll
0x10000000 - 0x10007000     C:\Program Files\Java\j2re1.4.2_09\bin\hpi.dll
0x76bf0000 - 0x76bfb000     C:\WINDOWS\system32\PSAPI.DLL
0x00390000 - 0x0039e000     C:\Program
Files\Java\j2re1.4.2_09\bin\verify.dll
0x003b0000 - 0x003c9000     C:\Program Files\Java\j2re1.4.2_09\bin\java.dll
0x003d0000 - 0x003de000     C:\Program Files\Java\j2re1.4.2_09\bin\zip.dll
0x02c60000 - 0x02c77000     C:\farm\sdljava\sdljava\lib\SDLJava.dll
0x02c80000 - 0x02cc1000     C:\farm\sdljava\sdljava\lib\SDL.dll
0x5ad70000 - 0x5ada8000     C:\WINDOWS\system32\uxtheme.dll
0x73760000 - 0x737a9000     C:\WINDOWS\system32\DDRAW.DLL
0x73bc0000 - 0x73bc6000     C:\WINDOWS\system32\DCIMAN32.dll
0x72280000 - 0x722aa000     C:\WINDOWS\system32\DINPUT.DLL
0x688f0000 - 0x688f9000     C:\WINDOWS\system32\HID.DLL
0x77920000 - 0x77a13000     C:\WINDOWS\system32\SETUPAPI.DLL
0x76c30000 - 0x76c5e000     C:\WINDOWS\system32\WINTRUST.dll
0x77a80000 - 0x77b14000     C:\WINDOWS\system32\CRYPT32.dll
0x77b20000 - 0x77b32000     C:\WINDOWS\system32\MSASN1.dll
0x76c90000 - 0x76cb8000     C:\WINDOWS\system32\IMAGEHLP.dll
0x73f10000 - 0x73f6c000     C:\WINDOWS\system32\DSOUND.DLL
0x774e0000 - 0x7761d000     C:\WINDOWS\system32\ole32.dll
0x77c00000 - 0x77c08000     C:\WINDOWS\system32\VERSION.dll
0x5ed00000 - 0x5edcc000     C:\WINDOWS\system32\OPENGL32.DLL
0x68b20000 - 0x68b40000     C:\WINDOWS\system32\GLU32.dll
0x03f10000 - 0x03f32000     C:\farm\sdljava\sdljava\lib\gljava.dll
0x03f40000 - 0x03f6f000     C:\farm\sdljava\sdljava\lib\glew32.dll

VM Arguments:
jvm_args: -Djava.library.path=C:\farm\sdljava\sdljava/lib
java_command: sdljava.example.spaceinvaders.SpaceInvaders

Environment Variables:
JAVA_HOME=C:\Program Files\Java\j2re1.4.2_09
PATH=C:\farm\sdljava\sdljava;C:\farm\sdljava\sdljava/lib;C:\farm\sdljava\sdljava/testdata;c:\ruby\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program
Files\Microsoft Visual Studio\Common\Tools\WinNT;C:\Program
Files\Microsoft Visual Studio\Common\MSDev98\Bin;C:\Program
Files\Microsoft Visual Studio\Common\Tools;C:\Program Files\Microsoft
Visual Studio\VC98\bin;C:\Program Files\Java\j2re1.4.2_09\bin;C:\ruby\bin
USERNAME=Administrator
OS=Windows_NT
PROCESSOR_IDENTIFIER=x86 Family 15 Model 2 Stepping 8, GenuineIntel


---------------  S Y S T E M  ---------------

OS: Windows XP Build 2600 Service Pack 2

CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2

Memory: 4k page, physical 261616k(89324k free), swap 633056k(468404k free)

vm_info: Java HotSpot(TM) Client VM (1.4.2_09-b05) for windows-x86,
built on Jul 25 2005 22:44:22 by "java_re" with MS VC++ 6.0

Re: [sdljava-users] Using multiple contexts with gljava

[Ivan Z. G. <iva...@ya...>]

Unfortunately I don't think this is currently possible.  The reason is
that SDL only supports one window currently.  SDL 2.0 I belive is
supposed to add multi-window capability.

Right now the GL context is initialized and created by the SDL layer
when setVideoMode() is called with the SDL_OPENGL flag set.  sdljava
doesn't create the contexts on its own.

I really wish we could have multiple windows but I don't see how its
currently possible...

-Ivan/

Gregor M=FCckl wrote:

>Hi!
>
>Using multiple contexts with gljava not really possible at the moment as=
 the=20
>underlying GLEW needs to be informed about context changes (provided, it=
 is=20
>compiled with support for context changes in the first place), but that=20
>function is not exported yet. However, I'll need it soon because I need =
more=20
>than one context in Moonlight|3D in the future.
>
>Could you please look into this matter? It's explained quite well on the=
 GLEW=20
>homepage.
>
>Regards,
>Gregor
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Power Architecture Resource Center: Free content, downloads, discussions=
,
>and more. http://solutions.newsforge.com/ibmarch.tmpl
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
> =20
>

[sdljava-users] Using multiple contexts with gljava

[Gregor <Gre...@gm...>]

Hi!

Using multiple contexts with gljava not really possible at the moment as the 
underlying GLEW needs to be informed about context changes (provided, it is 
compiled with support for context changes in the first place), but that 
function is not exported yet. However, I'll need it soon because I need more 
than one context in Moonlight|3D in the future.

Could you please look into this matter? It's explained quite well on the GLEW 
homepage.

Regards,
Gregor

Re: [sdljava-users] problem with the installation of SDLJava.

[Ivan Z. G. <iva...@ya...>]

Yes there appears to be some problem.  I'm very busy right now but I
will have a look at it as soon as I can.  sdljava should most certainly
work on windows and with eclipse so we'll make sure it does.

-Ivan/

mathieu wrote:

>Hi,
>I tried what you said Ivan (in fact, i've already tried that), and result is
>always the same.
>All my dll are in the same repertory, Eclipse seems to be well configurated
>: You can see that in the 2 jpg.
>
>Somebody have an idee on the problem ?
>  
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>

RE: [sdljava-users] problem with the installation of SDLJava.

[mathieu <mat...@ce...>]

Hi,
I tried what you said Ivan (in fact, i've already tried that), and result is
always the same.
All my dll are in the same repertory, Eclipse seems to be well configurated
: You can see that in the 2 jpg.

Somebody have an idee on the problem ?

Re: [sdljava-users] direct buffers in glu functions

[Ivan Z. G. <iva...@ya...>]

No problem Gregor it will be done.

Thanks,
-Ivan/

Gregor M=FCckl wrote:

>Hi!
>
>I'd like to make you aware that the glu function wrappers you provide al=
so=20
>require the use of direct buffers for small amounts of data. Would you p=
lease=20
>provide alternative implementations using arrays like you did for the=20
>ordinary opengl functions? I'd appreciate that very much.
>
>Regards,
>Gregor
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Power Architecture Resource Center: Free content, downloads, discussions=
,
>and more. http://solutions.newsforge.com/ibmarch.tmpl
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
> =20
>

Re: [sdljava-users] problem with the installation of SDLJava.

[Ivan Z. G. <iva...@ya...>]

Greetings Mathieu,

It should be fairly easy to run an sdljava programs from within Eclipse. 

The easier way is to put all the required SDL dlls in sdljava\lib
directory (SDL.dll, etc...)

Now just set one VM argument and it should work.  I just ran testsprite
from within Eclipse here without any problems.  Here is the screenshot
of how I set the arguments.

I hope this doesn't work differently under windows.  I'm able to run the
same tests from the command line on windows also by putting everything
in sdljava\lib and using just the one -D switch.  I will try with
Eclipse on Windows when I have time to see if that works.

If you want to do it how you are doing below I belive you have to
specify the absolute path shared library.  I know others initially had
problems with Eclipse but I thought it all worked now.  I don't have
problems myself.

Let me know if you have any luck.

-Ivan/

mathieu wrote:

> Hi!
>  
> I'm a newbie with sdljava and i've some difficulties to install it.
> After many hours it still doesn't work despite all the topics i've
> readen about this subject.
>  
> i'm using win XP and Eclipse. My VM argument configured in eclipse is
> "-Djava.library.path=D:\SDL\lib" and in this repertory there is
> 'SDL.DLL' , SDLjava.dll',... In ".\java\lib" i put the jar files of
> sdljava and finally SDL.DLL is in my 'system32' repertory.
>  
> i do my tests under Eclipse with the code :
>  
> /package testSDL;/
> // 
> /import sdljava.SDLMain;/
> // 
> /public class SDLMainTest {/
> // 
> / static {
>   System.out.println("test0");
>   System.loadLibrary("SDLjava");
>   System.out.println("test1");  
>  }
>  
>     public static void main(String[] args) {/
> /     try {
>       System.out.println("test2");
>       SDLMain.init(SDLMain.SDL_INIT_EVERYTHING);/
> // 
> /      System.out.println("INIT OKAY!");
>     
>      } catch (Exception e) {
>       System.out.println("INIT FAILED!");
>       e.printStackTrace();
>      }
>     } 
> }/
>  
> the result is :
>
> test0
> test1
> test2
> Native code library failed to load.
> java.lang.UnsatisfiedLinkError: no sdljava in java.library.path
>
> I tried a lot of thinks ... without results... Please help me, i'm
> deseperate ! :)
>
> (ps : sorry for my poor english, i'm French :-) )
>

[sdljava-users] direct buffers in glu functions

[Gregor <Gre...@gm...>]

Hi!

I'd like to make you aware that the glu function wrappers you provide also 
require the use of direct buffers for small amounts of data. Would you please 
provide alternative implementations using arrays like you did for the 
ordinary opengl functions? I'd appreciate that very much.

Regards,
Gregor

[sdljava-users] problem with the installation of SDLJava.

[mathieu <mat...@ce...>]

Hi!
 
I'm a newbie with sdljava and i've some difficulties to install it. After
many hours it still doesn't work despite all the topics i've readen about
this subject.
 
i'm using win XP and Eclipse. My VM argument configured in eclipse is
"-Djava.library.path=D:\SDL\lib" and in this repertory there is 'SDL.DLL' ,
SDLjava.dll',... In ".\java\lib" i put the jar files of sdljava and finally
SDL.DLL is in my 'system32' repertory.
 
i do my tests under Eclipse with the code :
 
package testSDL;
 
import sdljava.SDLMain;
 
public class SDLMainTest {
 
 static {
  System.out.println("test0");
  System.loadLibrary("SDLjava");
  System.out.println("test1");  
 }
 
    public static void main(String[] args) {
     try {
      System.out.println("test2");
      SDLMain.init(SDLMain.SDL_INIT_EVERYTHING);
 
      System.out.println("INIT OKAY!");
     
     } catch (Exception e) {
      System.out.println("INIT FAILED!");
      e.printStackTrace();
     }
    }  
}
 
the result is :
test0
test1
test2
Native code library failed to load. 
java.lang.UnsatisfiedLinkError: no sdljava in java.library.path

I tried a lot of thinks ... without results... Please help me, i'm
deseperate ! :)

(ps : sorry for my poor english, i'm French :-) )

Re: [sdljava-users] native array access methods added to gljava(opengl) binding!

[Gregor <Gre...@gm...>]

Hi!

These new functions work for me as far as I could determine until now. Many 
thanks!

Regards,
Gregor

On Saturday 17 September 2005 00:48, Ivan Z. Ganza wrote:
> Greetings!
>
> I've added native array access methods for all the methods which
> previously took NIO Buffers as a parameter. These methods can now be
> used instead of NIO buffers where appropriate.
>
> Please let me know if this works for you Gregor.  Also could you send me
> a blurb that explains where you would want to use native arrays versus
> NIO Buffers?  Still need to properly document this and would appreciate
> any help.
>
> Cheers,
> -Ivan/
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download it for free - -and be entered to win a 42" plasma tv or your very
> own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users

Re: [sdljava-users] native array access methods added to gljava(opengl) binding!

[Gregor <Gre...@gm...>]

Hi!

Stupid me! I just didn't look thoroughly enough. Well, now i see that it's 
there and I'm going to try it out as soon as possible.

Regards,
Gregor

On Saturday 17 September 2005 00:48, Ivan Z. Ganza wrote:
> Greetings!
>
> I've added native array access methods for all the methods which
> previously took NIO Buffers as a parameter. These methods can now be
> used instead of NIO buffers where appropriate.
>
> Please let me know if this works for you Gregor.  Also could you send me
> a blurb that explains where you would want to use native arrays versus
> NIO Buffers?  Still need to properly document this and would appreciate
> any help.
>
> Cheers,
> -Ivan/
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download it for free - -and be entered to win a 42" plasma tv or your very
> own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users

Re: [sdljava-users] native array access methods added to gljava(opengl) binding!

[Gregor <Gre...@gm...>]

Hi!

I've not been able to find any trace of that change in CVS. I really don't 
know what's wrong. Could you please verify that you indeed committed your 
changes? Thanks!

Regards
Gregor

On Saturday 17 September 2005 00:48, Ivan Z. Ganza wrote:
> Greetings!
>
> I've added native array access methods for all the methods which
> previously took NIO Buffers as a parameter. These methods can now be
> used instead of NIO buffers where appropriate.
>
> Please let me know if this works for you Gregor.  Also could you send me
> a blurb that explains where you would want to use native arrays versus
> NIO Buffers?  Still need to properly document this and would appreciate
> any help.
>
> Cheers,
> -Ivan/
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download it for free - -and be entered to win a 42" plasma tv or your very
> own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users

[sdljava-users] native array access methods added to gljava(opengl) binding!

[Ivan Z. G. <iva...@ya...>]

Greetings! 
 
I've added native array access methods for all the methods which
previously took NIO Buffers as a parameter. These methods can now be
used instead of NIO buffers where appropriate.

Please let me know if this works for you Gregor.  Also could you send me
a blurb that explains where you would want to use native arrays versus
NIO Buffers?  Still need to properly document this and would appreciate
any help.
 
Cheers, 
-Ivan/

Re: [sdljava-users] SWIG_glew_init();

[Ivan Z. G. <iva...@ya...>]

sdljava should integrate seamlessly with gljava.  Nothing should prevent
gljava from being used on its own though.  You just need to initialize
the library on your own -- which your already doing.  I'm going to split
out the gljava specific classes into their own jar (gljava.jar) soon as
well.  So you won't need to include any part of sdljava to work with it.

...in other news

I've added the method GlewImpl.init() which calls SWIG_glew_init() for
you.  Everyone should use this method from now on to initialize the
library on its own.

-Ivan/

Gregor M=FCckl wrote:

>Hi!
>
>This is perfectly good when someone uses SDL with OpenGL. However, I jus=
t want=20
>to mention that I use org.gljava.opengl without any SDL-related part of=20
>sdljava, because the rest of the UI is provided by gtk (with thorougly m=
ixed=20
>results, though). This means that I still need to call SWIG_glew_init=20
>directly. I agree that this is not very pretty, but it's a solution and =
I can=20
>live with it.
>
>Regards,
>Gregor
>
>On Tuesday 13 September 2005 05:10, Ivan Z. Ganza wrote:
> =20
>
>>Greetings,
>>
>>I've added code in SDLSurface.setVideoMode(int, int, int, long) which
>>calls SWIG_glew_init() if the surface has an OpenGL context.  I didn't
>>really like the idea of people having to calls this externally on their
>>own.  Please let me know if it causes any problems.
>>
>>-Ivan/
>>
>>
>>-------------------------------------------------------
>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Pract=
ices
>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing &=
 QA
>>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5=
sf
>>_______________________________________________
>>sdljava-users mailing list
>>sdl...@li...
>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>   =20
>>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by:
>Tame your development challenges with Apache's Geronimo App Server. Down=
load
>it for free - -and be entered to win a 42" plasma tv or your very own
>Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
> =20
>

Re: [sdljava-users] SWIG_glew_init();

[Gregor <Gre...@gm...>]

Hi!

This is perfectly good when someone uses SDL with OpenGL. However, I just want 
to mention that I use org.gljava.opengl without any SDL-related part of 
sdljava, because the rest of the UI is provided by gtk (with thorougly mixed 
results, though). This means that I still need to call SWIG_glew_init 
directly. I agree that this is not very pretty, but it's a solution and I can 
live with it.

Regards,
Gregor

On Tuesday 13 September 2005 05:10, Ivan Z. Ganza wrote:
> Greetings,
>
> I've added code in SDLSurface.setVideoMode(int, int, int, long) which
> calls SWIG_glew_init() if the surface has an OpenGL context.  I didn't
> really like the idea of people having to calls this externally on their
> own.  Please let me know if it causes any problems.
>
> -Ivan/
>
>
> -------------------------------------------------------
> 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

Re: [sdljava-users] Usage example for glGetDoublev

[Gregor <Gre...@gm...>]

Your numbers are pretty impressive. May I ask what CPU you used for these?=
=20
I've tested with the Sun J2SDK 1.5.0.04 on an Athlon XP 1800+ with 1GB main=
=20
memory, in case that matters. I forgot to mention that in my original email=
=2E=20
Sorry about that. And I really need a compiler/VM combo that can deal with=
=20
generics as my code is littered with uses of the new java.util generics. I=
=20
don't know if jamvm or gcj are there yet.

There seems to be a minor misunderstanding about glVertex3d and similar: th=
e=20
size of the expected data array is fixed. For example glVertex3f expects 3=
=20
floats and glVertex2d expects 2 doubles, etc... So for the majority of thes=
e=20
functions you really only pass fixed small amounts of data.

And about the benchmark: I wrote and ran that in about half a hour this=20
morning and there's no need to overly copyright such little amount of work =
as=20
that actually was. So give it whatever license you might see fit. I'm fine=
=20
with the GPL in particular if you add the right headers for me :-).

Ivan: Thanks for these changes. And I fully understand the need for scripts=
 to=20
generate the source code. The number of functions following the same patter=
n=20
in OpenGL is insane and anyone not autogenerating the bindings for them wou=
ld=20
be a fool.

Thanks for your support to both of you!

Regards,
Gregor

On Wednesday 14 September 2005 00:32, Robert Schuster wrote:
> Hi Gregor,
> this is an impressive nice benchmark. Look what our free VMs can achieve:
>
> rob@linkist ~/tmp/test/bench/buffer-vs-arrays $ LD_LIBRARY_PATH=3D. gij
> Benchmark running Test Benchmark$TestArrayReallocate for 1000000 times
> result: 2705
> running Test Benchmark$TestArrayAllocateOnce for 1000000 times
> result: 2242
> running Test Benchmark$TestByteBufferReallocate for 1000000 times
> result: 4329
> running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
> result: 1047
>
> (This is GCJ 4.0 somewhat.)
>
> rob@linkist ~/tmp/test/bench/buffer-vs-arrays $ LD_LIBRARY_PATH=3D. jamvm
> Benchmark running Test Benchmark$TestArrayReallocate for 1000000 times
> result: 1825
> running Test Benchmark$TestArrayAllocateOnce for 1000000 times
> result: 1443
> running Test Benchmark$TestByteBufferReallocate for 1000000 times
> result: 7916
> running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
> result: 278
> rob@linkist ~/tmp/test/bench/buffer-vs-arrays $
>
> (Both are interpreted only. JamVM has a handcrafted JNI implementation th=
at
> really outperforms the JDK)
>
> As a comparison my JDK 1.5.0 results:
> LD_LIBRARY_PATH=3D. /opt/sun-jdk-1.5.0/bin/java Benchmark
> running Test Benchmark$TestArrayReallocate for 1000000 times
> result: 484
> running Test Benchmark$TestArrayAllocateOnce for 1000000 times
> result: 386
> running Test Benchmark$TestByteBufferReallocate for 1000000 times
> result: 15891
> running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
> result: 287
>
> However your point seems to be valid. Frequent allocations of direct
> buffers kill performance. In my opinion this is very sad for Java because
> it means
>
> if (amountOfData < someMagicValue) {
> 	GL.glVertex3fv(new int[] { foo, baz, bar, ... });
> } else {
>         IntBuffer b =3D BufferUtils.createBuffer(...);
> 	b.put(...);
> 	GL.glVertex3fv(b);
> }
>
> Gregor would you mind giving your benchmark a GPL or GPL-compatible licen=
se
> so I may be allowed to put it into mauve (the free test suite)? I am sure
> Robert Lougher (JamVM) and the GCJ team is pretty interested about these
> results.
>
> Oh yes and you're right. For maximum control over performance GLJava shou=
ld
> provide OpenGL's v-functions with Java arrays exactly in the way you did =
it
> in the benchmark. And then the Javadoc should mention when to use which
> version ...
>
> cu
> Robert
>
> Gregor M=C3=BCckl wrote:
> > Hi!
> >
> > I've finally tried to benchmark java arrays and direct buffers in small
> > buffers of the size that would typically appear in OpenGL apps. The
> > results of the runs on my computer are:
> >
> > gregor@goose ~/progs/nio-benchmark $ LD_LIBRARY_PATH=3D. java Benchmark
> > running Test Benchmark$TestArrayReallocate for 1000000 times
> > result: 1033
> > running Test Benchmark$TestArrayAllocateOnce for 1000000 times
> > result: 817
> > running Test Benchmark$TestByteBufferReallocate for 1000000 times
> > result: 32803
> > running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
> > result: 560
> > gregor@goose ~/progs/nio-benchmark $ LD_LIBRARY_PATH=3D. java Benchmark
> > running Test Benchmark$TestArrayReallocate for 1000000 times
> > result: 1034
> > running Test Benchmark$TestArrayAllocateOnce for 1000000 times
> > result: 776
> > running Test Benchmark$TestByteBufferReallocate for 1000000 times
> > result: 34588
> > running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
> > result: 591
> > gregor@goose ~/progs/nio-benchmark $ LD_LIBRARY_PATH=3D. java Benchmark
> > running Test Benchmark$TestArrayReallocate for 1000000 times
> > result: 984
> > running Test Benchmark$TestArrayAllocateOnce for 1000000 times
> > result: 768
> > running Test Benchmark$TestByteBufferReallocate for 1000000 times
> > result: 35151
> > running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
> > result: 615
> > gregor@goose ~/progs/nio-benchmark $ LD_LIBRARY_PATH=3D. java Benchmark
> > running Test Benchmark$TestArrayReallocate for 1000000 times
> > result: 1093
> > running Test Benchmark$TestArrayAllocateOnce for 1000000 times
> > result: 847
> > running Test Benchmark$TestByteBufferReallocate for 1000000 times
> > result: 35321
> > running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
> > result: 623
> > gregor@goose ~/progs/nio-benchmark $ LD_LIBRARY_PATH=3D. java Benchmark
> > running Test Benchmark$TestArrayReallocate for 1000000 times
> > result: 730
> > running Test Benchmark$TestArrayAllocateOnce for 1000000 times
> > result: 575
> > running Test Benchmark$TestByteBufferReallocate for 1000000 times
> > result: 22455
> > running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
> > result: 438
> >
> > The source code for the benchmark is included. This clearly shows that
> > direct buffers are really only viable if you can avoid their allocation.
> > But now the problem is that caching ByteBuffers would add considerable
> > overhead to the results of the last measurements in both sourcecode
> > complexity and runtime. Furthermore, caching unused data structures in
> > Java is especially bad design and any suggestion to that end can easily
> > be seen as a sign of bad design elsewhere. And in reality it may really
> > not be feasible. I'm writing a 3d modelling tool which cannot apply
> > proper rendering optimizations because the geometry may essentially be
> > anything and change at any time to anything else. So I have to use
> > thousands of calls to glVertex3d(v) and similar.
> >
> > Compared to direct buffers even the reallocated arrays don't have so mu=
ch
> > added overhead. So I strongly suggest that you implement arrays at least
> > as an alternative interface. It's easy to overload functions in Java, so
> > this is not a problem.
> >
> > The source code to the benchmark is appended.
> >
> > Regards,
> > Gregor
> >
> > On Tuesday 13 September 2005 04:17, Ivan Z. Ganza wrote:
> >>Thanks for the very detailed information :-)
> >>
> >>The helpful class is sdljava.util.BufferUtil...which Robert kindly
> >>coded.  Interesting to have a look at the code inside...
> >>
> >>Please let us know if your able to make it work Gregor.
> >>
> >>-Ivan/
> >>
> >>Robert Schuster wrote:
> >>>Hi,
> >>>I just want to jump into the discussion because I was one of the perso=
ns
> >>>who suggested Ivan to use NIO buffers instead of Java arrays (and I ha=
ve
> >>>some small background about the topic from JNI and GNU Classpath
> >>> coding).
> >>>
> >>>>The biggest buffer I use that way is there to store a matrix of
> >>>>4x4 doubles, that is, 128 bytes.
> >>>
> >>>Perfect. This is really the point where you can use NIO buffers. It may
> >>> be look odd to you but a regular Java array is more troublesome than a
> >>> NIO buffer. The buffer is an object denoting a certain memory region.
> >>> Therefore you can think of it as a thin wrapper around a normal C arr=
ay
> >>> (or memory region that allocated with malloc/calloc).
> >>>
> >>>A Java array is something that lifes inside the JVM and can be
> >>> implemented very differently. NIO buffers and Java arrays have very
> >>> similar JNI functions to interact with them. Both have a function whi=
ch
> >>> returns a pointer so that you can modify the data in C-style. However
> >>> the array access function explicitly states that you *may* receive the
> >>> pointer to a copy of the original data (remember that Java arrays life
> >>> in the JVMs heap and may be moved around because of garbage collection
> >>> and memory compaction). This won't happen with NIO buffers.
> >>>
> >>>If you have a feeling that frequent bytebuffer instantiations would ha=
rm
> >>>the performance of your application then please have a look whether you
> >>>may not solve this problem in a different way (e.g. pooling buffers or
> >>>the like).
> >>>
> >>>>Using byte buffers may be a valid approach when working on large,
> >>>> uniform amounts of data like framebuffers. But that is not the case
> >>>> with geometry data for OpenGL. Using vertex arrays is almost out of
> >>>> question for me since the geometry data I have is very dynamic in
> >>>> every way.
> >>>
> >>>Definitely not. NIO buffers can be used wherever interaction with nati=
ve
> >>>machinery is involved. I once wrote a jinput plugin which uses the Lin=
ux
> >>>kernel's input system to access mouse/keyboard/joypad etc (You can find
> >>>the sources in the respective forums at javagaming.org). It makes heavy
> >>>use of NIO buffers even for such small amounts of data (key/button/axes
> >>>states) and I think it is a big win that the system's kernel can write
> >>>into the memory which it shares with my Java application.
> >>>
> >>>>Well, this is not trying to be a rant. I'm just not yet convinced that
> >>>>this is the right approach. It looks like far too much overhead to me,
> >>>>making all the OpenGL functions taking (small) arrays practically
> >>>>useless.
> >>>
> >>>Well, in which way could they be implemented otherwise? At one point y=
ou
> >>>will forced to create a buffer in memory (probably C). If you hand over
> >>>the data in Java arrays and copy it over into a malloc'ed memory region
> >>>then this would hit performance seriously (You need one copy operation
> >>>and one time malloc/free in GLJava's code.) With NIO buffers the JNI
> >>>implementation would simply return the buffer's pointer and call the
> >>>OpenGL function. The handling of the buffer (recreate it every time or
> >>> do some pooling) is up to you - the application programmer.
> >>>
> >>>>Maybe some
> >>>>benchmarking is in order to get some definitive answers, but I don't
> >>>> have enough time for that.
> >>>
> >>>Well I try to prove it with a bit of pseudo code. (I use pseudo code
> >>>because I dont know the JNI function names by heart. They are very
> >>>tedious ...)
> >>>
> >>>
> >>>1. With Java arrays
> >>>GL.java
> >>>
> >>>public class GL {
> >>> public native setSomethingv(int[] foo);
> >>>}
> >>>
> >>>net_sf_GL.c:
> >>>
> >>>setSomethingv(jvm, jobject java_array){
> >>>
> >>>  jint* thevalues =3D JVM_get_pointer_to_java_array(java_array); // may
> >>>copy
> >>>
> >>>  int size =3D JVM_get_size_of_java_array(java_array);
> >>>
> >>>  int* buffer =3D malloc(sizeof(int) * size);
> >>>
> >>>  memcopy(thevalues -> buffer, size * sizeof(int));
> >>>
> >>>  GLsetSomething(buffer);
> >>>
> >>>  JVM_release_access_to_java_array(java_array);
> >>>}
> >>>
> >>>2. With NIO buffers
> >>>
> >>>public class GL {
> >>> public native setSomethingv(IntBuffer foo);
> >>>}
> >>>net_sf_GL.c:
> >>>
> >>>setSomethingv(jvm, jobject nio_buffer){
> >>>
> >>>  jint* thevalues =3D JVM_get_pointer_of_nio_buffer(nio_buffer);
> >>>
> >>>  GLsetSomething(thevalues);
> >>>
> >>>  JVM_release_access_to_java_array(java_array);
> >>>}
> >>>
> >>>(I am broadly ignoring any type conversion oddities here.)
> >>>
> >>>Btw: There is a utility class in GLJava that creates direct Integer,
> >>> Long, Short, Double and Float buffers in one method call (In fact eve=
ry
> >>> newer OpenGL binding* has these methods ...)
> >>>
> >>>cu
> >>>Robert
> >>>
> >>>* JOGL, LwJGL
> >>>
> >>>
> >>>-------------------------------------------------------
> >>>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:
> Tame your development challenges with Apache's Geronimo App Server.
> Download it for free - -and be entered to win a 42" plasma tv or your very
> own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users

Re: [sdljava-users] Usage example for glGetDoublev

[Ivan Z. G. <iva...@ya...>]

Good discussion!

I will add the methods as you describe.

Regarding the documentation, once the first part is done, I'll let you
guys know.  Please give me pointers how I can improve the docs that I do
include.  I'm not sure I will be able to properly document where to use
one versus the other.

Thanks for all the discussion and feedback!

PS:  I will implement glGetDoublev in this manner soon so Gregor can
continue his work.  The rest will come later as I will need to write a
ruby script to create the actual source code for me...its way too much
typing for my old fingers ... ;-)

-Ivan/

Robert Schuster wrote:

>Hi Gregor,
>this is an impressive nice benchmark. Look what our free VMs can achieve=
:
>
>rob@linkist ~/tmp/test/bench/buffer-vs-arrays $ LD_LIBRARY_PATH=3D. gij =
Benchmark
>running Test Benchmark$TestArrayReallocate for 1000000 times
>result: 2705
>running Test Benchmark$TestArrayAllocateOnce for 1000000 times
>result: 2242
>running Test Benchmark$TestByteBufferReallocate for 1000000 times
>result: 4329
>running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
>result: 1047
>
>(This is GCJ 4.0 somewhat.)
>
>rob@linkist ~/tmp/test/bench/buffer-vs-arrays $ LD_LIBRARY_PATH=3D. jamv=
m Benchmark
>running Test Benchmark$TestArrayReallocate for 1000000 times
>result: 1825
>running Test Benchmark$TestArrayAllocateOnce for 1000000 times
>result: 1443
>running Test Benchmark$TestByteBufferReallocate for 1000000 times
>result: 7916
>running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
>result: 278
>rob@linkist ~/tmp/test/bench/buffer-vs-arrays $
>
>(Both are interpreted only. JamVM has a handcrafted JNI implementation t=
hat
>really outperforms the JDK)
>
>As a comparison my JDK 1.5.0 results:
>LD_LIBRARY_PATH=3D. /opt/sun-jdk-1.5.0/bin/java Benchmark
>running Test Benchmark$TestArrayReallocate for 1000000 times
>result: 484
>running Test Benchmark$TestArrayAllocateOnce for 1000000 times
>result: 386
>running Test Benchmark$TestByteBufferReallocate for 1000000 times
>result: 15891
>running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
>result: 287
>
>However your point seems to be valid. Frequent allocations of direct buf=
fers
>kill performance. In my opinion this is very sad for Java because it mea=
ns
>
>if (amountOfData < someMagicValue) {
>	GL.glVertex3fv(new int[] { foo, baz, bar, ... });
>} else {
>        IntBuffer b =3D BufferUtils.createBuffer(...);
>	b.put(...);
>	GL.glVertex3fv(b);
>}
>
>Gregor would you mind giving your benchmark a GPL or GPL-compatible lice=
nse so I
>may be allowed to put it into mauve (the free test suite)? I am sure Rob=
ert
>Lougher (JamVM) and the GCJ team is pretty interested about these result=
s.
>
>Oh yes and you're right. For maximum control over performance GLJava sho=
uld
>provide OpenGL's v-functions with Java arrays exactly in the way you did=
 it in
>the benchmark. And then the Javadoc should mention when to use which ver=
sion ...
>
>cu
>Robert
>
>Gregor M=C3=BCckl wrote:
> =20
>
>>Hi!
>>
>>I've finally tried to benchmark java arrays and direct buffers in small=
=20
>>buffers of the size that would typically appear in OpenGL apps. The res=
ults=20
>>of the runs on my computer are:
>>
>>gregor@goose ~/progs/nio-benchmark $ LD_LIBRARY_PATH=3D. java Benchmark
>>running Test Benchmark$TestArrayReallocate for 1000000 times
>>result: 1033
>>running Test Benchmark$TestArrayAllocateOnce for 1000000 times
>>result: 817
>>running Test Benchmark$TestByteBufferReallocate for 1000000 times
>>result: 32803
>>running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
>>result: 560
>>gregor@goose ~/progs/nio-benchmark $ LD_LIBRARY_PATH=3D. java Benchmark
>>running Test Benchmark$TestArrayReallocate for 1000000 times
>>result: 1034
>>running Test Benchmark$TestArrayAllocateOnce for 1000000 times
>>result: 776
>>running Test Benchmark$TestByteBufferReallocate for 1000000 times
>>result: 34588
>>running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
>>result: 591
>>gregor@goose ~/progs/nio-benchmark $ LD_LIBRARY_PATH=3D. java Benchmark
>>running Test Benchmark$TestArrayReallocate for 1000000 times
>>result: 984
>>running Test Benchmark$TestArrayAllocateOnce for 1000000 times
>>result: 768
>>running Test Benchmark$TestByteBufferReallocate for 1000000 times
>>result: 35151
>>running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
>>result: 615
>>gregor@goose ~/progs/nio-benchmark $ LD_LIBRARY_PATH=3D. java Benchmark
>>running Test Benchmark$TestArrayReallocate for 1000000 times
>>result: 1093
>>running Test Benchmark$TestArrayAllocateOnce for 1000000 times
>>result: 847
>>running Test Benchmark$TestByteBufferReallocate for 1000000 times
>>result: 35321
>>running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
>>result: 623
>>gregor@goose ~/progs/nio-benchmark $ LD_LIBRARY_PATH=3D. java Benchmark
>>running Test Benchmark$TestArrayReallocate for 1000000 times
>>result: 730
>>running Test Benchmark$TestArrayAllocateOnce for 1000000 times
>>result: 575
>>running Test Benchmark$TestByteBufferReallocate for 1000000 times
>>result: 22455
>>running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
>>result: 438
>>
>>The source code for the benchmark is included. This clearly shows that =
direct=20
>>buffers are really only viable if you can avoid their allocation. But n=
ow the=20
>>problem is that caching ByteBuffers would add considerable overhead to =
the=20
>>results of the last measurements in both sourcecode complexity and runt=
ime.=20
>>Furthermore, caching unused data structures in Java is especially bad d=
esign=20
>>and any suggestion to that end can easily be seen as a sign of bad desi=
gn=20
>>elsewhere. And in reality it may really not be feasible. I'm writing a =
3d=20
>>modelling tool which cannot apply proper rendering optimizations becaus=
e the=20
>>geometry may essentially be anything and change at any time to anything=
 else.=20
>>So I have to use thousands of calls to glVertex3d(v) and similar.
>>
>>Compared to direct buffers even the reallocated arrays don't have so mu=
ch=20
>>added overhead. So I strongly suggest that you implement arrays at leas=
t as=20
>>an alternative interface. It's easy to overload functions in Java, so t=
his is=20
>>not a problem.
>>
>>The source code to the benchmark is appended.
>>
>>Regards,
>>Gregor
>>
>>On Tuesday 13 September 2005 04:17, Ivan Z. Ganza wrote:
>>
>>   =20
>>
>>>Thanks for the very detailed information :-)
>>>
>>>The helpful class is sdljava.util.BufferUtil...which Robert kindly
>>>coded.  Interesting to have a look at the code inside...
>>>
>>>Please let us know if your able to make it work Gregor.
>>>
>>>-Ivan/
>>>
>>>Robert Schuster wrote:
>>>
>>>     =20
>>>
>>>>Hi,
>>>>I just want to jump into the discussion because I was one of the pers=
ons
>>>>who suggested Ivan to use NIO buffers instead of Java arrays (and I h=
ave
>>>>some small background about the topic from JNI and GNU Classpath codi=
ng).
>>>>
>>>>
>>>>       =20
>>>>
>>>>>The biggest buffer I use that way is there to store a matrix of
>>>>>4x4 doubles, that is, 128 bytes.
>>>>>         =20
>>>>>
>>>>Perfect. This is really the point where you can use NIO buffers. It m=
ay be
>>>>look odd to you but a regular Java array is more troublesome than a N=
IO
>>>>buffer. The buffer is an object denoting a certain memory region.
>>>>Therefore you can think of it as a thin wrapper around a normal C arr=
ay
>>>>(or memory region that allocated with malloc/calloc).
>>>>
>>>>A Java array is something that lifes inside the JVM and can be implem=
ented
>>>>very differently. NIO buffers and Java arrays have very similar JNI
>>>>functions to interact with them. Both have a function which returns a
>>>>pointer so that you can modify the data in C-style. However the array
>>>>access function explicitly states that you *may* receive the pointer =
to a
>>>>copy of the original data (remember that Java arrays life in the JVMs
>>>>heap and may be moved around because of garbage collection and memory
>>>>compaction). This won't happen with NIO buffers.
>>>>
>>>>If you have a feeling that frequent bytebuffer instantiations would h=
arm
>>>>the performance of your application then please have a look whether y=
ou
>>>>may not solve this problem in a different way (e.g. pooling buffers o=
r
>>>>the like).
>>>>
>>>>
>>>>       =20
>>>>
>>>>>Using byte buffers may be a valid approach when working on large, un=
iform
>>>>>amounts of data like framebuffers. But that is not the case with geo=
metry
>>>>>data for OpenGL. Using vertex arrays is almost out of question for m=
e
>>>>>since the geometry data I have is very dynamic in every way.
>>>>>         =20
>>>>>
>>>>Definitely not. NIO buffers can be used wherever interaction with nat=
ive
>>>>machinery is involved. I once wrote a jinput plugin which uses the Li=
nux
>>>>kernel's input system to access mouse/keyboard/joypad etc (You can fi=
nd
>>>>the sources in the respective forums at javagaming.org). It makes hea=
vy
>>>>use of NIO buffers even for such small amounts of data (key/button/ax=
es
>>>>states) and I think it is a big win that the system's kernel can writ=
e
>>>>into the memory which it shares with my Java application.
>>>>
>>>>
>>>>       =20
>>>>
>>>>>Well, this is not trying to be a rant. I'm just not yet convinced th=
at
>>>>>this is the right approach. It looks like far too much overhead to m=
e,
>>>>>making all the OpenGL functions taking (small) arrays practically
>>>>>useless.
>>>>>         =20
>>>>>
>>>>Well, in which way could they be implemented otherwise? At one point =
you
>>>>will forced to create a buffer in memory (probably C). If you hand ov=
er
>>>>the data in Java arrays and copy it over into a malloc'ed memory regi=
on
>>>>then this would hit performance seriously (You need one copy operatio=
n
>>>>and one time malloc/free in GLJava's code.) With NIO buffers the JNI
>>>>implementation would simply return the buffer's pointer and call the
>>>>OpenGL function. The handling of the buffer (recreate it every time o=
r do
>>>>some pooling) is up to you - the application programmer.
>>>>
>>>>
>>>>       =20
>>>>
>>>>>Maybe some
>>>>>benchmarking is in order to get some definitive answers, but I don't=
 have
>>>>>enough time for that.
>>>>>         =20
>>>>>
>>>>Well I try to prove it with a bit of pseudo code. (I use pseudo code
>>>>because I dont know the JNI function names by heart. They are very
>>>>tedious ...)
>>>>
>>>>
>>>>1. With Java arrays
>>>>GL.java
>>>>
>>>>public class GL {
>>>>public native setSomethingv(int[] foo);
>>>>}
>>>>
>>>>net_sf_GL.c:
>>>>
>>>>setSomethingv(jvm, jobject java_array){
>>>>
>>>> jint* thevalues =3D JVM_get_pointer_to_java_array(java_array); // ma=
y
>>>>copy
>>>>
>>>> int size =3D JVM_get_size_of_java_array(java_array);
>>>>
>>>> int* buffer =3D malloc(sizeof(int) * size);
>>>>
>>>> memcopy(thevalues -> buffer, size * sizeof(int));
>>>>
>>>> GLsetSomething(buffer);
>>>>
>>>> JVM_release_access_to_java_array(java_array);
>>>>}
>>>>
>>>>2. With NIO buffers
>>>>
>>>>public class GL {
>>>>public native setSomethingv(IntBuffer foo);
>>>>}
>>>>net_sf_GL.c:
>>>>
>>>>setSomethingv(jvm, jobject nio_buffer){
>>>>
>>>> jint* thevalues =3D JVM_get_pointer_of_nio_buffer(nio_buffer);
>>>>
>>>> GLsetSomething(thevalues);
>>>>
>>>> JVM_release_access_to_java_array(java_array);
>>>>}
>>>>
>>>>(I am broadly ignoring any type conversion oddities here.)
>>>>
>>>>Btw: There is a utility class in GLJava that creates direct Integer, =
Long,
>>>>Short, Double and Float buffers in one method call (In fact every new=
er
>>>>OpenGL binding* has these methods ...)
>>>>
>>>>cu
>>>>Robert
>>>>
>>>>* JOGL, LwJGL
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>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
>>>>       =20
>>>>
>>>-------------------------------------------------------
>>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Prac=
tices
>>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing =
& QA
>>>Security * Process Improvement & Measurement * http://www.sqe.com/bsce=
5sf
>>>_______________________________________________
>>>sdljava-users mailing list
>>>sdl...@li...
>>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>>     =20
>>>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by:
>Tame your development challenges with Apache's Geronimo App Server. Down=
load
>it for free - -and be entered to win a 42" plasma tv or your very own
>Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
> =20
>

Re: [sdljava-users] Usage example for glGetDoublev

[Robert S. <the...@gm...>]

Hi Gregor,
this is an impressive nice benchmark. Look what our free VMs can achieve:

rob@linkist ~/tmp/test/bench/buffer-vs-arrays $ LD_LIBRARY_PATH=. gij Benchmark
running Test Benchmark$TestArrayReallocate for 1000000 times
result: 2705
running Test Benchmark$TestArrayAllocateOnce for 1000000 times
result: 2242
running Test Benchmark$TestByteBufferReallocate for 1000000 times
result: 4329
running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
result: 1047

(This is GCJ 4.0 somewhat.)

rob@linkist ~/tmp/test/bench/buffer-vs-arrays $ LD_LIBRARY_PATH=. jamvm Benchmark
running Test Benchmark$TestArrayReallocate for 1000000 times
result: 1825
running Test Benchmark$TestArrayAllocateOnce for 1000000 times
result: 1443
running Test Benchmark$TestByteBufferReallocate for 1000000 times
result: 7916
running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
result: 278
rob@linkist ~/tmp/test/bench/buffer-vs-arrays $

(Both are interpreted only. JamVM has a handcrafted JNI implementation that
really outperforms the JDK)

As a comparison my JDK 1.5.0 results:
LD_LIBRARY_PATH=. /opt/sun-jdk-1.5.0/bin/java Benchmark
running Test Benchmark$TestArrayReallocate for 1000000 times
result: 484
running Test Benchmark$TestArrayAllocateOnce for 1000000 times
result: 386
running Test Benchmark$TestByteBufferReallocate for 1000000 times
result: 15891
running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
result: 287

However your point seems to be valid. Frequent allocations of direct buffers
kill performance. In my opinion this is very sad for Java because it means

if (amountOfData < someMagicValue) {
	GL.glVertex3fv(new int[] { foo, baz, bar, ... });
} else {
        IntBuffer b = BufferUtils.createBuffer(...);
	b.put(...);
	GL.glVertex3fv(b);
}

Gregor would you mind giving your benchmark a GPL or GPL-compatible license so I
may be allowed to put it into mauve (the free test suite)? I am sure Robert
Lougher (JamVM) and the GCJ team is pretty interested about these results.

Oh yes and you're right. For maximum control over performance GLJava should
provide OpenGL's v-functions with Java arrays exactly in the way you did it in
the benchmark. And then the Javadoc should mention when to use which version ...

cu
Robert

Gregor Mückl wrote:
> Hi!
> 
> I've finally tried to benchmark java arrays and direct buffers in small 
> buffers of the size that would typically appear in OpenGL apps. The results 
> of the runs on my computer are:
> 
> gregor@goose ~/progs/nio-benchmark $ LD_LIBRARY_PATH=. java Benchmark
> running Test Benchmark$TestArrayReallocate for 1000000 times
> result: 1033
> running Test Benchmark$TestArrayAllocateOnce for 1000000 times
> result: 817
> running Test Benchmark$TestByteBufferReallocate for 1000000 times
> result: 32803
> running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
> result: 560
> gregor@goose ~/progs/nio-benchmark $ LD_LIBRARY_PATH=. java Benchmark
> running Test Benchmark$TestArrayReallocate for 1000000 times
> result: 1034
> running Test Benchmark$TestArrayAllocateOnce for 1000000 times
> result: 776
> running Test Benchmark$TestByteBufferReallocate for 1000000 times
> result: 34588
> running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
> result: 591
> gregor@goose ~/progs/nio-benchmark $ LD_LIBRARY_PATH=. java Benchmark
> running Test Benchmark$TestArrayReallocate for 1000000 times
> result: 984
> running Test Benchmark$TestArrayAllocateOnce for 1000000 times
> result: 768
> running Test Benchmark$TestByteBufferReallocate for 1000000 times
> result: 35151
> running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
> result: 615
> gregor@goose ~/progs/nio-benchmark $ LD_LIBRARY_PATH=. java Benchmark
> running Test Benchmark$TestArrayReallocate for 1000000 times
> result: 1093
> running Test Benchmark$TestArrayAllocateOnce for 1000000 times
> result: 847
> running Test Benchmark$TestByteBufferReallocate for 1000000 times
> result: 35321
> running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
> result: 623
> gregor@goose ~/progs/nio-benchmark $ LD_LIBRARY_PATH=. java Benchmark
> running Test Benchmark$TestArrayReallocate for 1000000 times
> result: 730
> running Test Benchmark$TestArrayAllocateOnce for 1000000 times
> result: 575
> running Test Benchmark$TestByteBufferReallocate for 1000000 times
> result: 22455
> running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
> result: 438
> 
> The source code for the benchmark is included. This clearly shows that direct 
> buffers are really only viable if you can avoid their allocation. But now the 
> problem is that caching ByteBuffers would add considerable overhead to the 
> results of the last measurements in both sourcecode complexity and runtime. 
> Furthermore, caching unused data structures in Java is especially bad design 
> and any suggestion to that end can easily be seen as a sign of bad design 
> elsewhere. And in reality it may really not be feasible. I'm writing a 3d 
> modelling tool which cannot apply proper rendering optimizations because the 
> geometry may essentially be anything and change at any time to anything else. 
> So I have to use thousands of calls to glVertex3d(v) and similar.
> 
> Compared to direct buffers even the reallocated arrays don't have so much 
> added overhead. So I strongly suggest that you implement arrays at least as 
> an alternative interface. It's easy to overload functions in Java, so this is 
> not a problem.
> 
> The source code to the benchmark is appended.
> 
> Regards,
> Gregor
> 
> On Tuesday 13 September 2005 04:17, Ivan Z. Ganza wrote:
> 
>>Thanks for the very detailed information :-)
>>
>>The helpful class is sdljava.util.BufferUtil...which Robert kindly
>>coded.  Interesting to have a look at the code inside...
>>
>>Please let us know if your able to make it work Gregor.
>>
>>-Ivan/
>>
>>Robert Schuster wrote:
>>
>>>Hi,
>>>I just want to jump into the discussion because I was one of the persons
>>>who suggested Ivan to use NIO buffers instead of Java arrays (and I have
>>>some small background about the topic from JNI and GNU Classpath coding).
>>>
>>>
>>>>The biggest buffer I use that way is there to store a matrix of
>>>>4x4 doubles, that is, 128 bytes.
>>>
>>>Perfect. This is really the point where you can use NIO buffers. It may be
>>>look odd to you but a regular Java array is more troublesome than a NIO
>>>buffer. The buffer is an object denoting a certain memory region.
>>>Therefore you can think of it as a thin wrapper around a normal C array
>>>(or memory region that allocated with malloc/calloc).
>>>
>>>A Java array is something that lifes inside the JVM and can be implemented
>>>very differently. NIO buffers and Java arrays have very similar JNI
>>>functions to interact with them. Both have a function which returns a
>>>pointer so that you can modify the data in C-style. However the array
>>>access function explicitly states that you *may* receive the pointer to a
>>>copy of the original data (remember that Java arrays life in the JVMs
>>>heap and may be moved around because of garbage collection and memory
>>>compaction). This won't happen with NIO buffers.
>>>
>>>If you have a feeling that frequent bytebuffer instantiations would harm
>>>the performance of your application then please have a look whether you
>>>may not solve this problem in a different way (e.g. pooling buffers or
>>>the like).
>>>
>>>
>>>>Using byte buffers may be a valid approach when working on large, uniform
>>>>amounts of data like framebuffers. But that is not the case with geometry
>>>>data for OpenGL. Using vertex arrays is almost out of question for me
>>>>since the geometry data I have is very dynamic in every way.
>>>
>>>Definitely not. NIO buffers can be used wherever interaction with native
>>>machinery is involved. I once wrote a jinput plugin which uses the Linux
>>>kernel's input system to access mouse/keyboard/joypad etc (You can find
>>>the sources in the respective forums at javagaming.org). It makes heavy
>>>use of NIO buffers even for such small amounts of data (key/button/axes
>>>states) and I think it is a big win that the system's kernel can write
>>>into the memory which it shares with my Java application.
>>>
>>>
>>>>Well, this is not trying to be a rant. I'm just not yet convinced that
>>>>this is the right approach. It looks like far too much overhead to me,
>>>>making all the OpenGL functions taking (small) arrays practically
>>>>useless.
>>>
>>>Well, in which way could they be implemented otherwise? At one point you
>>>will forced to create a buffer in memory (probably C). If you hand over
>>>the data in Java arrays and copy it over into a malloc'ed memory region
>>>then this would hit performance seriously (You need one copy operation
>>>and one time malloc/free in GLJava's code.) With NIO buffers the JNI
>>>implementation would simply return the buffer's pointer and call the
>>>OpenGL function. The handling of the buffer (recreate it every time or do
>>>some pooling) is up to you - the application programmer.
>>>
>>>
>>>>Maybe some
>>>>benchmarking is in order to get some definitive answers, but I don't have
>>>>enough time for that.
>>>
>>>Well I try to prove it with a bit of pseudo code. (I use pseudo code
>>>because I dont know the JNI function names by heart. They are very
>>>tedious ...)
>>>
>>>
>>>1. With Java arrays
>>>GL.java
>>>
>>>public class GL {
>>> public native setSomethingv(int[] foo);
>>>}
>>>
>>>net_sf_GL.c:
>>>
>>>setSomethingv(jvm, jobject java_array){
>>>
>>>  jint* thevalues = JVM_get_pointer_to_java_array(java_array); // may
>>>copy
>>>
>>>  int size = JVM_get_size_of_java_array(java_array);
>>>
>>>  int* buffer = malloc(sizeof(int) * size);
>>>
>>>  memcopy(thevalues -> buffer, size * sizeof(int));
>>>
>>>  GLsetSomething(buffer);
>>>
>>>  JVM_release_access_to_java_array(java_array);
>>>}
>>>
>>>2. With NIO buffers
>>>
>>>public class GL {
>>> public native setSomethingv(IntBuffer foo);
>>>}
>>>net_sf_GL.c:
>>>
>>>setSomethingv(jvm, jobject nio_buffer){
>>>
>>>  jint* thevalues = JVM_get_pointer_of_nio_buffer(nio_buffer);
>>>
>>>  GLsetSomething(thevalues);
>>>
>>>  JVM_release_access_to_java_array(java_array);
>>>}
>>>
>>>(I am broadly ignoring any type conversion oddities here.)
>>>
>>>Btw: There is a utility class in GLJava that creates direct Integer, Long,
>>>Short, Double and Float buffers in one method call (In fact every newer
>>>OpenGL binding* has these methods ...)
>>>
>>>cu
>>>Robert
>>>
>>>* JOGL, LwJGL
>>>
>>>
>>>-------------------------------------------------------
>>>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

Re: [sdljava-users] Usage example for glGetDoublev

[Gregor <Gre...@gm...>]

Hi!

I've finally tried to benchmark java arrays and direct buffers in small 
buffers of the size that would typically appear in OpenGL apps. The results 
of the runs on my computer are:

gregor@goose ~/progs/nio-benchmark $ LD_LIBRARY_PATH=. java Benchmark
running Test Benchmark$TestArrayReallocate for 1000000 times
result: 1033
running Test Benchmark$TestArrayAllocateOnce for 1000000 times
result: 817
running Test Benchmark$TestByteBufferReallocate for 1000000 times
result: 32803
running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
result: 560
gregor@goose ~/progs/nio-benchmark $ LD_LIBRARY_PATH=. java Benchmark
running Test Benchmark$TestArrayReallocate for 1000000 times
result: 1034
running Test Benchmark$TestArrayAllocateOnce for 1000000 times
result: 776
running Test Benchmark$TestByteBufferReallocate for 1000000 times
result: 34588
running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
result: 591
gregor@goose ~/progs/nio-benchmark $ LD_LIBRARY_PATH=. java Benchmark
running Test Benchmark$TestArrayReallocate for 1000000 times
result: 984
running Test Benchmark$TestArrayAllocateOnce for 1000000 times
result: 768
running Test Benchmark$TestByteBufferReallocate for 1000000 times
result: 35151
running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
result: 615
gregor@goose ~/progs/nio-benchmark $ LD_LIBRARY_PATH=. java Benchmark
running Test Benchmark$TestArrayReallocate for 1000000 times
result: 1093
running Test Benchmark$TestArrayAllocateOnce for 1000000 times
result: 847
running Test Benchmark$TestByteBufferReallocate for 1000000 times
result: 35321
running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
result: 623
gregor@goose ~/progs/nio-benchmark $ LD_LIBRARY_PATH=. java Benchmark
running Test Benchmark$TestArrayReallocate for 1000000 times
result: 730
running Test Benchmark$TestArrayAllocateOnce for 1000000 times
result: 575
running Test Benchmark$TestByteBufferReallocate for 1000000 times
result: 22455
running Test Benchmark$TestByteBufferAllocateOnce for 1000000 times
result: 438

The source code for the benchmark is included. This clearly shows that direct 
buffers are really only viable if you can avoid their allocation. But now the 
problem is that caching ByteBuffers would add considerable overhead to the 
results of the last measurements in both sourcecode complexity and runtime. 
Furthermore, caching unused data structures in Java is especially bad design 
and any suggestion to that end can easily be seen as a sign of bad design 
elsewhere. And in reality it may really not be feasible. I'm writing a 3d 
modelling tool which cannot apply proper rendering optimizations because the 
geometry may essentially be anything and change at any time to anything else. 
So I have to use thousands of calls to glVertex3d(v) and similar.

Compared to direct buffers even the reallocated arrays don't have so much 
added overhead. So I strongly suggest that you implement arrays at least as 
an alternative interface. It's easy to overload functions in Java, so this is 
not a problem.

The source code to the benchmark is appended.

Regards,
Gregor

On Tuesday 13 September 2005 04:17, Ivan Z. Ganza wrote:
> Thanks for the very detailed information :-)
>
> The helpful class is sdljava.util.BufferUtil...which Robert kindly
> coded.  Interesting to have a look at the code inside...
>
> Please let us know if your able to make it work Gregor.
>
> -Ivan/
>
> Robert Schuster wrote:
> >Hi,
> >I just want to jump into the discussion because I was one of the persons
> > who suggested Ivan to use NIO buffers instead of Java arrays (and I have
> > some small background about the topic from JNI and GNU Classpath coding).
> >
> >>The biggest buffer I use that way is there to store a matrix of
> >>4x4 doubles, that is, 128 bytes.
> >
> >Perfect. This is really the point where you can use NIO buffers. It may be
> > look odd to you but a regular Java array is more troublesome than a NIO
> > buffer. The buffer is an object denoting a certain memory region.
> > Therefore you can think of it as a thin wrapper around a normal C array
> > (or memory region that allocated with malloc/calloc).
> >
> >A Java array is something that lifes inside the JVM and can be implemented
> > very differently. NIO buffers and Java arrays have very similar JNI
> > functions to interact with them. Both have a function which returns a
> > pointer so that you can modify the data in C-style. However the array
> > access function explicitly states that you *may* receive the pointer to a
> > copy of the original data (remember that Java arrays life in the JVMs
> > heap and may be moved around because of garbage collection and memory
> > compaction). This won't happen with NIO buffers.
> >
> >If you have a feeling that frequent bytebuffer instantiations would harm
> > the performance of your application then please have a look whether you
> > may not solve this problem in a different way (e.g. pooling buffers or
> > the like).
> >
> >>Using byte buffers may be a valid approach when working on large, uniform
> >>amounts of data like framebuffers. But that is not the case with geometry
> >>data for OpenGL. Using vertex arrays is almost out of question for me
> >> since the geometry data I have is very dynamic in every way.
> >
> >Definitely not. NIO buffers can be used wherever interaction with native
> >machinery is involved. I once wrote a jinput plugin which uses the Linux
> >kernel's input system to access mouse/keyboard/joypad etc (You can find
> > the sources in the respective forums at javagaming.org). It makes heavy
> > use of NIO buffers even for such small amounts of data (key/button/axes
> > states) and I think it is a big win that the system's kernel can write
> > into the memory which it shares with my Java application.
> >
> >>Well, this is not trying to be a rant. I'm just not yet convinced that
> >> this is the right approach. It looks like far too much overhead to me,
> >> making all the OpenGL functions taking (small) arrays practically
> >> useless.
> >
> >Well, in which way could they be implemented otherwise? At one point you
> > will forced to create a buffer in memory (probably C). If you hand over
> > the data in Java arrays and copy it over into a malloc'ed memory region
> > then this would hit performance seriously (You need one copy operation
> > and one time malloc/free in GLJava's code.) With NIO buffers the JNI
> > implementation would simply return the buffer's pointer and call the
> > OpenGL function. The handling of the buffer (recreate it every time or do
> > some pooling) is up to you - the application programmer.
> >
> >>Maybe some
> >>benchmarking is in order to get some definitive answers, but I don't have
> >>enough time for that.
> >
> >Well I try to prove it with a bit of pseudo code. (I use pseudo code
> > because I dont know the JNI function names by heart. They are very
> > tedious ...)
> >
> >
> >1. With Java arrays
> >GL.java
> >
> >public class GL {
> >  public native setSomethingv(int[] foo);
> >}
> >
> >net_sf_GL.c:
> >
> >setSomethingv(jvm, jobject java_array){
> >
> >   jint* thevalues = JVM_get_pointer_to_java_array(java_array); // may
> > copy
> >
> >   int size = JVM_get_size_of_java_array(java_array);
> >
> >   int* buffer = malloc(sizeof(int) * size);
> >
> >   memcopy(thevalues -> buffer, size * sizeof(int));
> >
> >   GLsetSomething(buffer);
> >
> >   JVM_release_access_to_java_array(java_array);
> >}
> >
> >2. With NIO buffers
> >
> >public class GL {
> >  public native setSomethingv(IntBuffer foo);
> >}
> >net_sf_GL.c:
> >
> >setSomethingv(jvm, jobject nio_buffer){
> >
> >   jint* thevalues = JVM_get_pointer_of_nio_buffer(nio_buffer);
> >
> >   GLsetSomething(thevalues);
> >
> >   JVM_release_access_to_java_array(java_array);
> >}
> >
> >(I am broadly ignoring any type conversion oddities here.)
> >
> >Btw: There is a utility class in GLJava that creates direct Integer, Long,
> >Short, Double and Float buffers in one method call (In fact every newer
> > OpenGL binding* has these methods ...)
> >
> >cu
> >Robert
> >
> >* JOGL, LwJGL
> >
> >
> >-------------------------------------------------------
> >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