sdljava-users — General Discussion about sdljava and gljava

[sdljava-users] OT: Invitation to participate in research project

[Ben A. <ben...@st...>]

Hello there

I would greatly appreciate a small amount of your time to assist with
my doctoral research at The University of Newcastle. The research
concerns open source licensing and we're seeking developers working on
Java projects. The research is supervised, ethics-approved, anonymous
and results will be freely available. Participation will also provide a
custom licensing report for your project. To learn more, please visit:

   http://licensing-research.newcastle.edu.au

Thanks for reading this email, and I hope you'll consider participating.

Best regards
Ben Alex

(My apologies for being off-topic; this list will not be emailed again)

Re: [sdljava-users] java3d and vecmath licensed as free software

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

Cool!  Thanks for sending the info about this!

Robert Schuster wrote:

>and here is the link
>
>http://forums.java.net/jive/thread.jspa?threadID=27494
>
>regards
>robert
>
>Robert Schuster schrieb:
>  
>
>>hi,
>>unbelievable but true: java3d as well as the vecmath package are now
>>licensed under the gpl + linking exception (what gnu classpath & openjdk
>>uses).
>>
>>now the vecmath in sdljava can be replaced with that.
>>
>>regards
>>robert
>>
>>
>>
>>------------------------------------------------------------------------
>>
>>-------------------------------------------------------------------------
>>This SF.net email is sponsored by DB2 Express
>>Download DB2 Express C - the FREE version of DB2 express and take
>>control of your XML. No limits. Just data. Click to get it now.
>>http://sourceforge.net/powerbar/db2/
>>
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>sdljava-users mailing list
>>sdl...@li...
>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>    
>>
>
>  
>
>------------------------------------------------------------------------
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by DB2 Express
>Download DB2 Express C - the FREE version of DB2 express and take
>control of your XML. No limits. Just data. Click to get it now.
>http://sourceforge.net/powerbar/db2/
>
>------------------------------------------------------------------------
>
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>  
>

Re: [sdljava-users] java3d and vecmath licensed as free software

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

and here is the link

http://forums.java.net/jive/thread.jspa?threadID=3D27494

regards
robert

Robert Schuster schrieb:
> hi,
> unbelievable but true: java3d as well as the vecmath package are now
> licensed under the gpl + linking exception (what gnu classpath & openjd=
k
> uses).
>=20
> now the vecmath in sdljava can be replaced with that.
>=20
> regards
> robert
>=20
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20
> -----------------------------------------------------------------------=
--
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users

[sdljava-users] java3d and vecmath licensed as free software

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

hi,
unbelievable but true: java3d as well as the vecmath package are now
licensed under the gpl + linking exception (what gnu classpath & openjdk
uses).

now the vecmath in sdljava can be replaced with that.

regards
robert

Re: [sdljava-users] (no subject)

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

Hi Thomas,

I see the problem.  The culprit is the code in SDLSurface.java:

public int blitSurface(SDLRect src, SDLSurface dstSurface, SDLRect dst) 
throws SDLException {
    if(src == null) {
        src = new SDLRect(0, 0, getWidth(), getHeight());
    }
    if (dst == null) {
        dst = new SDLRect(0, 0, -1, -1);
    }
    return SWIG_SDLVideo.SWIG_SDL_BlitSurface_FAST(swigSurface,
                               src.getX(),
                               src.getY(),
                               src.getWidth(),
                               src.getHeight(),
                               dstSurface.getSwigSurface(),
                               dst.getX(),
                               dst.getY(),
                               dst.getWidth(),
                               dst.getHeight()
                               );
    }

As you can see in the code I'm unwrapping the Rect, for speed, and only 
passing the values -- after the call there is only a status of the blit 
returned so SDLJava has no knowledge about updating the positions in the 
rect that you passed in the call.

Hrrmmm....I have to admit I did not consider your scenerio.  However I 
do think we need to support it.  If the original SDL works that way, we 
should be doing the same thing in the java world. 

Its not clear to me how this can be done while still being fast.  If we 
want to update the rect passed intot the java call, the rect has to be 
passed to the C code, _by value_, and then it will be updated in C and 
passed back again to java by value once again.  This  won't be very 
efficient.  I could be wrong but right now I am fairly sure it will all 
by pass by value in this case.

If I can figure out a way to fix this and still be efficient I will get 
the code in within a week or two.  Not sure if you have the time but 
feel free to dig into the code if you wish....I'm happy to accept 
contributions.

Cheers,
-Ivan/




Thomas Beck wrote:

>Hi @all!
>
>My name is Thomas, I'm a german software engeneer and I've got a problem with sdljava.I didn't get solved by extensively searching the web.
>
>Question:
>Why is it not allowed to blit a surface onto another (surface.blitsurface(SrcRect,screen,DestRect)by giving the rectangle negative values. For example: my Position on the main-surface where to blit is DestRect.x=-200; DestRect.y=-10; DestRect.w=100;DestRect.h=100
>
>I read in the sdljava-doc that if the blitting succeeds the blitted coordinates are written back to the DestRect. When I do the blit, my DestRect.x is at -200 so I would think that the blitting was done without any errors - but the blitting was done on (0|0) - no matter what negative values I choose...it's erverytime on (0|0)
>
>This blitting with negative values is very important for scrolling and is no problem in the c++ binding or the sdl.net binding..so is there a cause to do so? Or is it a bug (and if so.. will it be fixed)
>
>Greetings to all of you, Thomas
>  
>

[sdljava-users] (no subject)

[Thomas B. <19...@gm...>]

Hi @all!

My name is Thomas, I'm a german software engeneer and I've got a problem with sdljava.I didn't get solved by extensively searching the web.

Question:
Why is it not allowed to blit a surface onto another (surface.blitsurface(SrcRect,screen,DestRect)by giving the rectangle negative values. For example: my Position on the main-surface where to blit is DestRect.x=-200; DestRect.y=-10; DestRect.w=100;DestRect.h=100

I read in the sdljava-doc that if the blitting succeeds the blitted coordinates are written back to the DestRect. When I do the blit, my DestRect.x is at -200 so I would think that the blitting was done without any errors - but the blitting was done on (0|0) - no matter what negative values I choose...it's erverytime on (0|0)

This blitting with negative values is very important for scrolling and is no problem in the c++ binding or the sdl.net binding..so is there a cause to do so? Or is it a bug (and if so.. will it be fixed)

Greetings to all of you, Thomas
-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

Re: [sdljava-users] Problems with javaSDL and NetBeans

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

Greeting Eifer,

Were you ever able to solve the problem?

The reason is that the path the path to the sdljava dll or shared 
library needs to be passed to the VM as 
-Djava.library.path=<PATH_TO_DLL_OR_SO>

Eifer Der Claw wrote:

>
> Hello:
>  
> How can i configure SDL to run projects with  netbeans? I´d included 
> the JAR library in NetBeans but it doesn´t compile.
> The error message is:
>  
> Native code library failed to load.
> java.lang.UnsatisfiedLinkError: no sdljava in java.library.path
> Java Result: 1
> ____________________________________________________
>  
>  
>  
> Please sorry about my English.
> Thanks.
>
>  
>
>------------------------------------------------------------------------
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys-and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
>------------------------------------------------------------------------
>
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>  
>

Re: [sdljava-users] Is there no matching binding for SDL_GetKeyState()

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

Greetings,

My applogies this has not yet been implemented.  I will have a look at 
implementing it....

-Ivan/

not_given wrote:

> I've looked in the Javadoc API and have found classes for the 
> MouseState, etc, but KeyState seems to be absent. Has this not been 
> implemented yet or am I looking in the wrong place?
>
>------------------------------------------------------------------------
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys-and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
>------------------------------------------------------------------------
>
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>  
>

[sdljava-users] Is there no matching binding for SDL_GetKeyState()

[not_given <nss...@gm...>]

I've looked in the Javadoc API and have found classes for the MouseState,
etc, but KeyState seems to be absent. Has this not been implemented yet or
am I looking in the wrong place?

[sdljava-users] Problems with javaSDL and NetBeans

[Eifer D. C. <eif...@gm...>]

Hello:

How can i configure SDL to run projects with  netbeans? I=B4d included the =
JAR
library in NetBeans but it doesn=B4t compile.
The error message is:

Native code library failed to load.
java.lang.UnsatisfiedLinkError: no sdljava in java.library.path
Java Result: 1
____________________________________________________



Please sorry about my English.
Thanks.

Re: [sdljava-users] Don't you want to release your work ?

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

Greetings Yoann!

The problem with the memory leak should be fixed but someone sent me a 
patch recently which fixes another issue -- I've yet to apply to patch 
to CVS though.

The reason for lack of releases has been mostly due to my lack of time 
and laziness.  I've been very busy and I don't like to make releases 
without properly testing them.  Currently I don't have a windows dev env 
so I wouldn't be able to test the release on windows.  Also I could not 
build binaries, however, a kind soul offered to do this for me so that 
is no longer an issue.

Currently the only developer is myself.  I could really use the help of 
a windows developer, so far nobody has stepped forward though.

Any contribution you would be willing to make to improve the project 
would be greatly appreciated.  I would be happy to add other developers 
who may have more time them myself.  The interest into SDL java seems to 
be pretty small though, and I've never had people email me showing 
interest in joining the team.

-Ivan/

Yoann Mercier wrote:

>I've been programming with SDLJava for few weeks and I had some problem with
>effiency. After reading the last threads here, it seems to be caused by memory
>leaks and stuff like that but I know you're working on it.
>
>Also, the last release is 2 years old. Why aren't there more releases ? Even if
>some things aren't fixed yet, that would be great to show your last
>improvements.
>
>How many people are working on SDLJava ? It seems to be an elitiste project and
>that's not going to attract programmers and users.
>
>Why isn't there a website dedicated to SDLJava ? Actually, I could set it up as
>I have some experience but I need more time. All tutorials on the internet are
>focused on c/c++ and that's the only way to learn how to use SDLJava, though
>there is the API.
>
>I'm asking all these questions because I find SDLJava a great idea and don't
>want to see it die because of a loss of interest.
>
>----------------------------------------------------------------
>This message was sent using IMP, the Internet Messaging Program.
>
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier.
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>  
>

[sdljava-users] Don't you want to release your work ?

[Yoann M. <yoa...@et...>]

I've been programming with SDLJava for few weeks and I had some problem with
effiency. After reading the last threads here, it seems to be caused by memo=
ry
leaks and stuff like that but I know you're working on it.

Also, the last release is 2 years old. Why aren't there more releases ? Even=
 if
some things aren't fixed yet, that would be great to show your last
improvements.

How many people are working on SDLJava ? It seems to be an elitiste project =
and
that's not going to attract programmers and users.

Why isn't there a website dedicated to SDLJava ? Actually, I could set it up=
 as
I have some experience but I need more time. All tutorials on the internet a=
re
focused on c/c++ and that's the only way to learn how to use SDLJava, though
there is the API.

I'm asking all these questions because I find SDLJava a great idea and don't
want to see it die because of a loss of interest.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: [sdljava-users] Building jni files fails on x86_64

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

Hi J=E9r=F4me,

Thanks for noticing this and the patch!  I've udpated the Makefile in CVS.

Cheers,
-Ivan/

J=E9r=F4me Marant wrote:

>Hi,
>
>sdljava JNI libraries won't build on many archictectures such as x86_64 =
without
>position-independent code.
>
>Here is the required patch:
>
>=3D=3D=3D=3D=3D
>--- etc/build/linux/Makefile.orig	2005-02-20 23:19:13.000000000 +0100
>+++ etc/build/linux/Makefile	2006-11-26 14:18:44.844731127 +0100
>@@ -2,7 +2,7 @@
>=20
> CC =3D gcc
>=20
>-CFLAGS=3D-O3
>+CFLAGS=3D-O3 -fPIC
>=20
> INCLUDE=3D-I. -I$(JAVA_HOME)/include -I$(JAVA_HOME)/include/linux -I/us=
r/include -I/usr/include/SDL -I/usr/local/include -I/usr/local/include/SD=
L
>=20
>=3D=3D=3D=3D=3D
>
>Regards,
>
> =20
>

[sdljava-users] Building jni files fails on x86_64

[<jm...@fr...>]

Hi,

sdljava JNI libraries won't build on many archictectures such as x86_64 w=
ithout
position-independent code.

Here is the required patch:

=3D=3D=3D=3D=3D
--- etc/build/linux/Makefile.orig	2005-02-20 23:19:13.000000000 +0100
+++ etc/build/linux/Makefile	2006-11-26 14:18:44.844731127 +0100
@@ -2,7 +2,7 @@
=20
 CC =3D gcc
=20
-CFLAGS=3D-O3
+CFLAGS=3D-O3 -fPIC
=20
 INCLUDE=3D-I. -I$(JAVA_HOME)/include -I$(JAVA_HOME)/include/linux -I/usr=
/include -I/usr/include/SDL -I/usr/local/include -I/usr/local/include/SDL
=20
=3D=3D=3D=3D=3D

Regards,

--=20
J=E9r=F4me Marant

Re: [sdljava-users] Possible memory leak in SWIG_SDLVideo / SDL_Surface / SWIG_SDLImage (Ivan Z. Ganza)

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

Greetings Jesper,

I will add the caching as you suggest.  Thanks for point that out!  I 
did only half the job I should have.  At least on the C side it does 
using cached RECT's rather the making new ones.  Now we'll do the same 
thing on the java side.

We'll get those Cursor routines added as well.

Really appreciate your offer of help with the binaries!

Cheers,
-Ivan/

Jesper Juul / Soup Games wrote:

>Two other things for the wish list:
>
>1) I am really missing the SDL Cursor routines.
>
>2) My application had a lot of garbage collection pauses - I ran a 
>memory profile and found  that the vast majority of memory allocation 
>was done in blitSurface in SDLSurface.java, where 1-2 SDLRect 
>instances are created for every blit. I tried modifying this to reuse 
>the same SDLRects, and this radically decreased the number of garbage 
>collections.
>setClipRect also creates a new instance for every call, and can be 
>made to reuse the same instance.
>I don't know how this fits with SWIG?
>
>
>     /**
>      * Cache for blitsurface
>      */
>     private SDLRect blitsurfacecache_s=new SDLRect();
>
>     /**
>      * Cache for blitsurface
>      */
>     private SDLRect blitsurfacecache_d=new SDLRect();
>
>
>     public int blitSurface(SDLRect src, SDLSurface dstSurface, 
>SDLRect dst) throws SDLException {
>         if(src == null) {
>             src = blitsurfacecache_s;
>             src.x=0;
>             src.y=0;
>             src.width=getWidth();
>             src.height=getHeight();
>          //     new SDLRect(0, 0, getWidth(), getHeight());
>         }
>         if (dst == null) {
>             dst = blitsurfacecache_d;
>             dst.x=0;
>             dst.y=0;
>             dst.width=-1;
>             dst.height=-1;
>             //dst = new SDLRect(0, 0, -1, -1);
>         }
>         return SWIG_SDLVideo.SWIG_SDL_BlitSurface_FAST(swigSurface,
>                                                        src.getX(),
>                                                        src.getY(),
>                                                        src.getWidth(),
>                                                        src.getHeight(),
>                                                        dstSurface.getSwigSurface(),
>                                                        dst.getX(),
>                                                        dst.getY(),
>                                                        dst.getWidth(),
>                                                        dst.getHeight()
>                                                        );
>     }
>
>I will be happy to build the Windows binaries.
>
>
>-Jesper
>
>
>At 24-09-2006 15:15, Ivan wrote:
>  
>
>>I will fix all instances, thanks for pointing those out.  I plan to do
>>the fixes tomorrow at some point.
>>
>>Thanks for the wishlist, I agree we should find a way to get all that in.
>>
>>I remember adding code for YUV but I'm not really sure what YUV does so
>>I don't know how to test it properly.
>>
>>The core dump problem on videoDriverName baffled me for a while, then I
>>gave up to go to more important things, its quite strange.
>>
>>Regarding SDL_Sound I wasn't sure if people actually use it?  Are people
>>using this?  And why would you use that instead of the Mixer?
>>
>>For Windows we just need to get into CVS the scripts that are needed to
>>build the various binaries.  Most of that is there already -- so there
>>shouldn't be too much work.  When we have a release someone needs to be
>>so kind as to build me the binaries, and send them to me so I can add
>>them to the release archive.
>>
>>-Ivan/
>>    
>>
>
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys -- and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>  
>

Re: [sdljava-users] Possible memory leak in SWIG_SDLVideo / SDL_Surface / SWIG_SDLImage (Ivan Z. Ganza)

[Jesper J. / S. G. <je...@so...>]

Two other things for the wish list:

1) I am really missing the SDL Cursor routines.

2) My application had a lot of garbage collection pauses - I ran a 
memory profile and found  that the vast majority of memory allocation 
was done in blitSurface in SDLSurface.java, where 1-2 SDLRect 
instances are created for every blit. I tried modifying this to reuse 
the same SDLRects, and this radically decreased the number of garbage 
collections.
setClipRect also creates a new instance for every call, and can be 
made to reuse the same instance.
I don't know how this fits with SWIG?


     /**
      * Cache for blitsurface
      */
     private SDLRect blitsurfacecache_s=new SDLRect();

     /**
      * Cache for blitsurface
      */
     private SDLRect blitsurfacecache_d=new SDLRect();


     public int blitSurface(SDLRect src, SDLSurface dstSurface, 
SDLRect dst) throws SDLException {
         if(src == null) {
             src = blitsurfacecache_s;
             src.x=0;
             src.y=0;
             src.width=getWidth();
             src.height=getHeight();
          //     new SDLRect(0, 0, getWidth(), getHeight());
         }
         if (dst == null) {
             dst = blitsurfacecache_d;
             dst.x=0;
             dst.y=0;
             dst.width=-1;
             dst.height=-1;
             //dst = new SDLRect(0, 0, -1, -1);
         }
         return SWIG_SDLVideo.SWIG_SDL_BlitSurface_FAST(swigSurface,
                                                        src.getX(),
                                                        src.getY(),
                                                        src.getWidth(),
                                                        src.getHeight(),
                                                        dstSurface.getSwigSurface(),
                                                        dst.getX(),
                                                        dst.getY(),
                                                        dst.getWidth(),
                                                        dst.getHeight()
                                                        );
     }

I will be happy to build the Windows binaries.


-Jesper


At 24-09-2006 15:15, Ivan wrote:
>I will fix all instances, thanks for pointing those out.  I plan to do
>the fixes tomorrow at some point.
>
>Thanks for the wishlist, I agree we should find a way to get all that in.
>
>I remember adding code for YUV but I'm not really sure what YUV does so
>I don't know how to test it properly.
>
>The core dump problem on videoDriverName baffled me for a while, then I
>gave up to go to more important things, its quite strange.
>
>Regarding SDL_Sound I wasn't sure if people actually use it?  Are people
>using this?  And why would you use that instead of the Mixer?
>
>For Windows we just need to get into CVS the scripts that are needed to
>build the various binaries.  Most of that is there already -- so there
>shouldn't be too much work.  When we have a release someone needs to be
>so kind as to build me the binaries, and send them to me so I can add
>them to the release archive.
>
>-Ivan/

Re: [sdljava-users] Possible memory leak in SWIG_SDLVideo / SDL_Surface / SWIG_SDLImage

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

Greetings,

I've implemented the fixes as suggested and the code is checked into CVS.

Before I checked in the changes I tagged the source as 
"PRE_MEMORY_LEAK_FIX" and afterwards I tagged as "POST_MEMORY_LEAK_FIXES".

Please let me know if there are any problems.

Cheers,
-Ivan/

Patric Rufflar wrote:

>Hi Ivan,
>
>You're welcome.
>I'm glad that I could help improving sdljava. :)
>
>By the way: SWIG_SDLTTF and SWIG_SDLGfx contain faulty constructors of 
>SDL_Surfaces, too. Please set false to true to fix this.
>
>Now I cannot see any other memory leaks (for now ;-) )
>
>And for now, I can't await that other points of my wishlist will come true :)
>- new sdljava release :)
>- new sdljava release for windows (oh, please. But maybe I have some free time 
>in the future and have a look how to set up a suitable build environment)
>- Support ffmpeg
>- full YUV Support (or do we have a complete and tested support already?)
>- Investigation of some rare core dumps. For example, SDLVideo.videoDriverName() 
>always crashes on my machine (windows, directx).
>- Support SDL_sound library
>
>Patric
>
>
>
>Ivan Z. Ganza schrieb:
>  
>
>>Hi Patric,
>>
>>I didn't even have a chance to look at it properly and you've already 
>>solved it! 
>>
>>Thanks so much for the detailed look you had at this.  Will go over it, 
>>it looks good.  The only problem is we have to change the way SWIG 
>>auto-generates the code.  For now I'll just patch the file as you've 
>>shown.  Eventually I'll need to figure out how to get SWIG to generate 
>>the wrapper code with that change in place.  We don't really generate 
>>the wrapper code often so it should be alright.  The only time would be 
>>when making the wrappers for a new OS or if it was required for some 
>>other reason like a new SDL version, etc....
>>
>>Will let you know when its in.
>>
>>Cheers,
>>-Ivan/
>>
>>Patric Rufflar wrote:
>>
>>    
>>
>>>Hi Ivan, hi all,
>>>
>>>After playing around with the patched source I realized that
>>>there is another critical memory problem.
>>>
>>>At first, please have a look at the jni definition inside SWIG_SDLVideoJNI
>>>
>>>public final static native void SDL_FreeSurface(long jarg1);
>>>public final static native void delete_SDL_Surface(long jarg1);
>>>public final static native long new_SDL_Surface();
>>>
>>>
>>>The first method, SDL_FreeSurface(), is ok. It does what it name 
>>>suggests, it calls the corresponding native SDL method.
>>>
>>>The other two methods seems to me dummy native methods for 
>>>contructors/destructors.  The original SDL_surface.c does not contain 
>>>any constructors/destructors, because it's pure c.
>>>So I think these jni calls do nothing.
>>>
>>>
>>>Ok, let's now have a look at SDLSurface.freeSurface() which will be 
>>>called on its finalization.
>>>
>>>    public void freeSurface() throws SDLException {
>>>	SWIG_SDLVideo.SDL_FreeSurface(swigSurface);
>>>	swigSurface = null;
>>>	pixelData   = null;
>>>    }
>>>
>>>As we can see, the real surface of the embedded SDL_Surface proxy object 
>>>will be freed. But what happens if there are other valid references to 
>>>this proxy object? It's memory pointer to the sdl surface is not valid 
>>>anymore, freeing this object may end up in a core dump.
>>>
>>>Now let's have a look at SDL_Surface finalization method, delete():
>>>
>>>  public void delete() {
>>>    if(swigCPtr != 0 && swigCMemOwn) {
>>>      swigCMemOwn = false;
>>>      SWIG_SDLVideoJNI.delete_SDL_Surface(swigCPtr);
>>>    }
>>>    swigCPtr = 0;
>>>  }
>>>
>>>This method calls the jni delete method, which is only a dummy. The real 
>>>memory is not freed. This is the memory leak.
>>>
>>>Because some SDL_Surface objects seem to be created without referenced 
>>>by a SDLSurface. But I have to admit that I cannot give an example in 
>>>the source right now.
>>>
>>>To fix these two problems, I suggest the following solution:
>>>
>>>Changes at SDLSurface:
>>>    public void freeSurface() throws SDLException {
>>>	SWIG_SDLVideo.SDL_FreeSurface(swigSurface); <<--delete this line
>>>	swigSurface = null;
>>>	pixelData   = null;
>>>    }
>>>
>>>
>>>Changes at SDL_Surface:
>>>  public void delete() {
>>>    if(swigCPtr != 0 && swigCMemOwn) {
>>>      SWIG_SDLVideo.SDL_FreeSurface(this); // As you can see, 		 
>>>//delete_SDL_Surface() has been replaced by the correct method.
>>>      swigCMemOwn = false;
>>>    }
>>>    swigCPtr = 0;
>>>  }
>>>
>>>
>>>This patch will ensure, that the finalization of the proxy object 
>>>(SDLSurface) will lead to freeing the surface not it's sdljava interface 
>>>to it (SDL_Surface). This fixed the memory problems in my application ;)
>>>
>>>To find those problems I am creating / deleting many surfaces in my 
>>>application. And It seems that there is at least another (less lossy) 
>>>memory leak which eats up memory.
>>>
>>>And I also want to add that the methods of SWIG_SDLImage seems to be 
>>>affected by the memory leak which I previously described, too.
>>>
>>>
>>>Best Regards
>>>Patric Rufflar
>>>
>>>
>>>
>>>Ivan Z. Ganza schrieb:
>>> 
>>>
>>>      
>>>
>>>>Greetings,
>>>>
>>>>Thanks for finding this.  Yes this is a serious problem.
>>>>
>>>>I need to do figure out how to get SWIG to set that flag to true instead 
>>>>of false, then the leak should be eleminated.  The code there is 
>>>>auto-generated by SWIG from the .i files.  In the worst case I can 
>>>>manually run a script after to post-process that stuff and fix it that 
>>>>way.  Either way it will be fixed.
>>>>
>>>>Cheers,
>>>>-Ivan/
>>>>
>>>>Jesper Juul / Soup Games wrote:
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>I wanted to post about this for a long time - I agre there is a leak 
>>>>>. So far I've worked around it by wrapping all Surfaces in a custom 
>>>>>object that calls dispose() in the finalizer.
>>>>>
>>>>>
>>>>>-Jesper
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>I was wondering a long time why my application needs more and more RAM.
>>>>>>I took a while to track down a possible memory leak.
>>>>>>It seems to be located in sdljava.x.swig.SWIG_SDLVideo .
>>>>>>
>>>>>>The following methods seems to be affected:
>>>>>>SDL_ConvertSurface(), SDL_DisplayFormat() and SDL_DisplayFormatAlpha()
>>>>>>
>>>>>>I am not sure at the moment, but maybe other methods have the same problem:
>>>>>>SDL_SetVideoMode(), SDL_CreateRGBSurface(), SWIG_SDL_LoadBMP(),
>>>>>>SWIG_SDL_CreateRGBSurfaceFrom()
>>>>>>
>>>>>>Please have a look at the last line of all methods:
>>>>>>return (cPtr == 0) ? null : new SDL_Surface(cPtr, false);
>>>>>>
>>>>>>As you can easily see, false indicates that the new surface cannot free
>>>>>>the memory because some other surface seems to also use it. But this is
>>>>>>not true, the surface has just been created, no other surface does own
>>>>>>this memory area.
>>>>>>
>>>>>>So this bug should be fixed when setting the second argument of the
>>>>>>surface constructors to true.
>>>>>>
>>>>>>Ivan, would you please verify the problem?
>>>>>>Thank you.
>>>>>>
>>>>>>Best Regards,
>>>>>>Patric
>>>>>>  
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>-------------------------------------------------------------------------
>>>>>Using Tomcat but need to do more? Need to support web services, security?
>>>>>Get stuff done quickly with pre-integrated technology to make your job easier
>>>>>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>>>>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>>>>_______________________________________________
>>>>>sdljava-users mailing list
>>>>>sdl...@li...
>>>>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>-------------------------------------------------------------------------
>>>>Using Tomcat but need to do more? Need to support web services, security?
>>>>Get stuff done quickly with pre-integrated technology to make your job easier
>>>>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>>>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>>>_______________________________________________
>>>>sdljava-users mailing list
>>>>sdl...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>>>
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>-------------------------------------------------------------------------
>>>Take Surveys. Earn Cash. Influence the Future of IT
>>>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>>>opinions on IT & business topics through brief surveys -- and earn cash
>>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>>_______________________________________________
>>>sdljava-users mailing list
>>>sdl...@li...
>>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>> 
>>>
>>>      
>>>
>>-------------------------------------------------------------------------
>>Take Surveys. Earn Cash. Influence the Future of IT
>>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>>opinions on IT & business topics through brief surveys -- and earn cash
>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>_______________________________________________
>>sdljava-users mailing list
>>sdl...@li...
>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>
>>
>>    
>>
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys -- and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>  
>

Re: [sdljava-users] Possible memory leak in SWIG_SDLVideo / SDL_Surface / SWIG_SDLImage

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

HI Patric,

I will fix all instances, thanks for pointing those out.  I plan to do 
the fixes tomorrow at some point.

Thanks for the wishlist, I agree we should find a way to get all that in.

I remember adding code for YUV but I'm not really sure what YUV does so 
I don't know how to test it properly.

The core dump problem on videoDriverName baffled me for a while, then I 
gave up to go to more important things, its quite strange.

Regarding SDL_Sound I wasn't sure if people actually use it?  Are people 
using this?  And why would you use that instead of the Mixer?

For Windows we just need to get into CVS the scripts that are needed to 
build the various binaries.  Most of that is there already -- so there 
shouldn't be too much work.  When we have a release someone needs to be 
so kind as to build me the binaries, and send them to me so I can add 
them to the release archive.

-Ivan/

Patric Rufflar wrote:

>Hi Ivan,
>
>You're welcome.
>I'm glad that I could help improving sdljava. :)
>
>By the way: SWIG_SDLTTF and SWIG_SDLGfx contain faulty constructors of 
>SDL_Surfaces, too. Please set false to true to fix this.
>
>Now I cannot see any other memory leaks (for now ;-) )
>
>And for now, I can't await that other points of my wishlist will come true :)
>- new sdljava release :)
>- new sdljava release for windows (oh, please. But maybe I have some free time 
>in the future and have a look how to set up a suitable build environment)
>- Support ffmpeg
>- full YUV Support (or do we have a complete and tested support already?)
>- Investigation of some rare core dumps. For example, SDLVideo.videoDriverName() 
>always crashes on my machine (windows, directx).
>- Support SDL_sound library
>
>Patric
>
>
>
>Ivan Z. Ganza schrieb:
>  
>
>>Hi Patric,
>>
>>I didn't even have a chance to look at it properly and you've already 
>>solved it! 
>>
>>Thanks so much for the detailed look you had at this.  Will go over it, 
>>it looks good.  The only problem is we have to change the way SWIG 
>>auto-generates the code.  For now I'll just patch the file as you've 
>>shown.  Eventually I'll need to figure out how to get SWIG to generate 
>>the wrapper code with that change in place.  We don't really generate 
>>the wrapper code often so it should be alright.  The only time would be 
>>when making the wrappers for a new OS or if it was required for some 
>>other reason like a new SDL version, etc....
>>
>>Will let you know when its in.
>>
>>Cheers,
>>-Ivan/
>>
>>Patric Rufflar wrote:
>>
>>    
>>
>>>Hi Ivan, hi all,
>>>
>>>After playing around with the patched source I realized that
>>>there is another critical memory problem.
>>>
>>>At first, please have a look at the jni definition inside SWIG_SDLVideoJNI
>>>
>>>public final static native void SDL_FreeSurface(long jarg1);
>>>public final static native void delete_SDL_Surface(long jarg1);
>>>public final static native long new_SDL_Surface();
>>>
>>>
>>>The first method, SDL_FreeSurface(), is ok. It does what it name 
>>>suggests, it calls the corresponding native SDL method.
>>>
>>>The other two methods seems to me dummy native methods for 
>>>contructors/destructors.  The original SDL_surface.c does not contain 
>>>any constructors/destructors, because it's pure c.
>>>So I think these jni calls do nothing.
>>>
>>>
>>>Ok, let's now have a look at SDLSurface.freeSurface() which will be 
>>>called on its finalization.
>>>
>>>    public void freeSurface() throws SDLException {
>>>	SWIG_SDLVideo.SDL_FreeSurface(swigSurface);
>>>	swigSurface = null;
>>>	pixelData   = null;
>>>    }
>>>
>>>As we can see, the real surface of the embedded SDL_Surface proxy object 
>>>will be freed. But what happens if there are other valid references to 
>>>this proxy object? It's memory pointer to the sdl surface is not valid 
>>>anymore, freeing this object may end up in a core dump.
>>>
>>>Now let's have a look at SDL_Surface finalization method, delete():
>>>
>>>  public void delete() {
>>>    if(swigCPtr != 0 && swigCMemOwn) {
>>>      swigCMemOwn = false;
>>>      SWIG_SDLVideoJNI.delete_SDL_Surface(swigCPtr);
>>>    }
>>>    swigCPtr = 0;
>>>  }
>>>
>>>This method calls the jni delete method, which is only a dummy. The real 
>>>memory is not freed. This is the memory leak.
>>>
>>>Because some SDL_Surface objects seem to be created without referenced 
>>>by a SDLSurface. But I have to admit that I cannot give an example in 
>>>the source right now.
>>>
>>>To fix these two problems, I suggest the following solution:
>>>
>>>Changes at SDLSurface:
>>>    public void freeSurface() throws SDLException {
>>>	SWIG_SDLVideo.SDL_FreeSurface(swigSurface); <<--delete this line
>>>	swigSurface = null;
>>>	pixelData   = null;
>>>    }
>>>
>>>
>>>Changes at SDL_Surface:
>>>  public void delete() {
>>>    if(swigCPtr != 0 && swigCMemOwn) {
>>>      SWIG_SDLVideo.SDL_FreeSurface(this); // As you can see, 		 
>>>//delete_SDL_Surface() has been replaced by the correct method.
>>>      swigCMemOwn = false;
>>>    }
>>>    swigCPtr = 0;
>>>  }
>>>
>>>
>>>This patch will ensure, that the finalization of the proxy object 
>>>(SDLSurface) will lead to freeing the surface not it's sdljava interface 
>>>to it (SDL_Surface). This fixed the memory problems in my application ;)
>>>
>>>To find those problems I am creating / deleting many surfaces in my 
>>>application. And It seems that there is at least another (less lossy) 
>>>memory leak which eats up memory.
>>>
>>>And I also want to add that the methods of SWIG_SDLImage seems to be 
>>>affected by the memory leak which I previously described, too.
>>>
>>>
>>>Best Regards
>>>Patric Rufflar
>>>
>>>
>>>
>>>Ivan Z. Ganza schrieb:
>>> 
>>>
>>>      
>>>
>>>>Greetings,
>>>>
>>>>Thanks for finding this.  Yes this is a serious problem.
>>>>
>>>>I need to do figure out how to get SWIG to set that flag to true instead 
>>>>of false, then the leak should be eleminated.  The code there is 
>>>>auto-generated by SWIG from the .i files.  In the worst case I can 
>>>>manually run a script after to post-process that stuff and fix it that 
>>>>way.  Either way it will be fixed.
>>>>
>>>>Cheers,
>>>>-Ivan/
>>>>
>>>>Jesper Juul / Soup Games wrote:
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>I wanted to post about this for a long time - I agre there is a leak 
>>>>>. So far I've worked around it by wrapping all Surfaces in a custom 
>>>>>object that calls dispose() in the finalizer.
>>>>>
>>>>>
>>>>>-Jesper
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>I was wondering a long time why my application needs more and more RAM.
>>>>>>I took a while to track down a possible memory leak.
>>>>>>It seems to be located in sdljava.x.swig.SWIG_SDLVideo .
>>>>>>
>>>>>>The following methods seems to be affected:
>>>>>>SDL_ConvertSurface(), SDL_DisplayFormat() and SDL_DisplayFormatAlpha()
>>>>>>
>>>>>>I am not sure at the moment, but maybe other methods have the same problem:
>>>>>>SDL_SetVideoMode(), SDL_CreateRGBSurface(), SWIG_SDL_LoadBMP(),
>>>>>>SWIG_SDL_CreateRGBSurfaceFrom()
>>>>>>
>>>>>>Please have a look at the last line of all methods:
>>>>>>return (cPtr == 0) ? null : new SDL_Surface(cPtr, false);
>>>>>>
>>>>>>As you can easily see, false indicates that the new surface cannot free
>>>>>>the memory because some other surface seems to also use it. But this is
>>>>>>not true, the surface has just been created, no other surface does own
>>>>>>this memory area.
>>>>>>
>>>>>>So this bug should be fixed when setting the second argument of the
>>>>>>surface constructors to true.
>>>>>>
>>>>>>Ivan, would you please verify the problem?
>>>>>>Thank you.
>>>>>>
>>>>>>Best Regards,
>>>>>>Patric
>>>>>>  
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>-------------------------------------------------------------------------
>>>>>Using Tomcat but need to do more? Need to support web services, security?
>>>>>Get stuff done quickly with pre-integrated technology to make your job easier
>>>>>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>>>>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>>>>_______________________________________________
>>>>>sdljava-users mailing list
>>>>>sdl...@li...
>>>>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>-------------------------------------------------------------------------
>>>>Using Tomcat but need to do more? Need to support web services, security?
>>>>Get stuff done quickly with pre-integrated technology to make your job easier
>>>>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>>>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>>>_______________________________________________
>>>>sdljava-users mailing list
>>>>sdl...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>>>
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>-------------------------------------------------------------------------
>>>Take Surveys. Earn Cash. Influence the Future of IT
>>>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>>>opinions on IT & business topics through brief surveys -- and earn cash
>>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>>_______________________________________________
>>>sdljava-users mailing list
>>>sdl...@li...
>>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>> 
>>>
>>>      
>>>
>>-------------------------------------------------------------------------
>>Take Surveys. Earn Cash. Influence the Future of IT
>>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>>opinions on IT & business topics through brief surveys -- and earn cash
>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>_______________________________________________
>>sdljava-users mailing list
>>sdl...@li...
>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>
>>
>>    
>>
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys -- and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>  
>

Re: [sdljava-users] Possible memory leak in SWIG_SDLVideo / SDL_Surface / SWIG_SDLImage

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

Hi Ivan,

You're welcome.
I'm glad that I could help improving sdljava. :)

By the way: SWIG_SDLTTF and SWIG_SDLGfx contain faulty constructors of 
SDL_Surfaces, too. Please set false to true to fix this.

Now I cannot see any other memory leaks (for now ;-) )

And for now, I can't await that other points of my wishlist will come true :)
- new sdljava release :)
- new sdljava release for windows (oh, please. But maybe I have some free time 
in the future and have a look how to set up a suitable build environment)
- Support ffmpeg
- full YUV Support (or do we have a complete and tested support already?)
- Investigation of some rare core dumps. For example, SDLVideo.videoDriverName() 
always crashes on my machine (windows, directx).
- Support SDL_sound library

Patric



Ivan Z. Ganza schrieb:
> Hi Patric,
> 
> I didn't even have a chance to look at it properly and you've already 
> solved it! 
> 
> Thanks so much for the detailed look you had at this.  Will go over it, 
> it looks good.  The only problem is we have to change the way SWIG 
> auto-generates the code.  For now I'll just patch the file as you've 
> shown.  Eventually I'll need to figure out how to get SWIG to generate 
> the wrapper code with that change in place.  We don't really generate 
> the wrapper code often so it should be alright.  The only time would be 
> when making the wrappers for a new OS or if it was required for some 
> other reason like a new SDL version, etc....
> 
> Will let you know when its in.
> 
> Cheers,
> -Ivan/
> 
> Patric Rufflar wrote:
> 
>> Hi Ivan, hi all,
>>
>> After playing around with the patched source I realized that
>> there is another critical memory problem.
>>
>> At first, please have a look at the jni definition inside SWIG_SDLVideoJNI
>>
>> public final static native void SDL_FreeSurface(long jarg1);
>> public final static native void delete_SDL_Surface(long jarg1);
>> public final static native long new_SDL_Surface();
>>
>>
>> The first method, SDL_FreeSurface(), is ok. It does what it name 
>> suggests, it calls the corresponding native SDL method.
>>
>> The other two methods seems to me dummy native methods for 
>> contructors/destructors.  The original SDL_surface.c does not contain 
>> any constructors/destructors, because it's pure c.
>> So I think these jni calls do nothing.
>>
>>
>> Ok, let's now have a look at SDLSurface.freeSurface() which will be 
>> called on its finalization.
>>
>>     public void freeSurface() throws SDLException {
>> 	SWIG_SDLVideo.SDL_FreeSurface(swigSurface);
>> 	swigSurface = null;
>> 	pixelData   = null;
>>     }
>>
>> As we can see, the real surface of the embedded SDL_Surface proxy object 
>> will be freed. But what happens if there are other valid references to 
>> this proxy object? It's memory pointer to the sdl surface is not valid 
>> anymore, freeing this object may end up in a core dump.
>>
>> Now let's have a look at SDL_Surface finalization method, delete():
>>
>>   public void delete() {
>>     if(swigCPtr != 0 && swigCMemOwn) {
>>       swigCMemOwn = false;
>>       SWIG_SDLVideoJNI.delete_SDL_Surface(swigCPtr);
>>     }
>>     swigCPtr = 0;
>>   }
>>
>> This method calls the jni delete method, which is only a dummy. The real 
>> memory is not freed. This is the memory leak.
>>
>> Because some SDL_Surface objects seem to be created without referenced 
>> by a SDLSurface. But I have to admit that I cannot give an example in 
>> the source right now.
>>
>> To fix these two problems, I suggest the following solution:
>>
>> Changes at SDLSurface:
>>     public void freeSurface() throws SDLException {
>> 	SWIG_SDLVideo.SDL_FreeSurface(swigSurface); <<--delete this line
>> 	swigSurface = null;
>> 	pixelData   = null;
>>     }
>>
>>
>> Changes at SDL_Surface:
>>   public void delete() {
>>     if(swigCPtr != 0 && swigCMemOwn) {
>>       SWIG_SDLVideo.SDL_FreeSurface(this); // As you can see, 		 
>> //delete_SDL_Surface() has been replaced by the correct method.
>>       swigCMemOwn = false;
>>     }
>>     swigCPtr = 0;
>>   }
>>
>>
>> This patch will ensure, that the finalization of the proxy object 
>> (SDLSurface) will lead to freeing the surface not it's sdljava interface 
>> to it (SDL_Surface). This fixed the memory problems in my application ;)
>>
>> To find those problems I am creating / deleting many surfaces in my 
>> application. And It seems that there is at least another (less lossy) 
>> memory leak which eats up memory.
>>
>> And I also want to add that the methods of SWIG_SDLImage seems to be 
>> affected by the memory leak which I previously described, too.
>>
>>
>> Best Regards
>> Patric Rufflar
>>
>>
>>
>> Ivan Z. Ganza schrieb:
>>  
>>
>>> Greetings,
>>>
>>> Thanks for finding this.  Yes this is a serious problem.
>>>
>>> I need to do figure out how to get SWIG to set that flag to true instead 
>>> of false, then the leak should be eleminated.  The code there is 
>>> auto-generated by SWIG from the .i files.  In the worst case I can 
>>> manually run a script after to post-process that stuff and fix it that 
>>> way.  Either way it will be fixed.
>>>
>>> Cheers,
>>> -Ivan/
>>>
>>> Jesper Juul / Soup Games wrote:
>>>
>>>    
>>>
>>>> I wanted to post about this for a long time - I agre there is a leak 
>>>> . So far I've worked around it by wrapping all Surfaces in a custom 
>>>> object that calls dispose() in the finalizer.
>>>>
>>>>
>>>> -Jesper
>>>>
>>>>
>>>>
>>>>      
>>>>
>>>>> I was wondering a long time why my application needs more and more RAM.
>>>>> I took a while to track down a possible memory leak.
>>>>> It seems to be located in sdljava.x.swig.SWIG_SDLVideo .
>>>>>
>>>>> The following methods seems to be affected:
>>>>> SDL_ConvertSurface(), SDL_DisplayFormat() and SDL_DisplayFormatAlpha()
>>>>>
>>>>> I am not sure at the moment, but maybe other methods have the same problem:
>>>>> SDL_SetVideoMode(), SDL_CreateRGBSurface(), SWIG_SDL_LoadBMP(),
>>>>> SWIG_SDL_CreateRGBSurfaceFrom()
>>>>>
>>>>> Please have a look at the last line of all methods:
>>>>> return (cPtr == 0) ? null : new SDL_Surface(cPtr, false);
>>>>>
>>>>> As you can easily see, false indicates that the new surface cannot free
>>>>> the memory because some other surface seems to also use it. But this is
>>>>> not true, the surface has just been created, no other surface does own
>>>>> this memory area.
>>>>>
>>>>> So this bug should be fixed when setting the second argument of the
>>>>> surface constructors to true.
>>>>>
>>>>> Ivan, would you please verify the problem?
>>>>> Thank you.
>>>>>
>>>>> Best Regards,
>>>>> Patric
>>>>>   
>>>>>
>>>>>        
>>>>>
>>>> -------------------------------------------------------------------------
>>>> Using Tomcat but need to do more? Need to support web services, security?
>>>> Get stuff done quickly with pre-integrated technology to make your job easier
>>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>>> _______________________________________________
>>>> sdljava-users mailing list
>>>> sdl...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>>>
>>>>
>>>>      
>>>>
>>> -------------------------------------------------------------------------
>>> Using Tomcat but need to do more? Need to support web services, security?
>>> Get stuff done quickly with pre-integrated technology to make your job easier
>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>> _______________________________________________
>>> sdljava-users mailing list
>>> sdl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>>
>>>
>>>    
>>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>> opinions on IT & business topics through brief surveys -- and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> sdljava-users mailing list
>> sdl...@li...
>> https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>  
>>
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users
> 
> 

Re: [sdljava-users] Possible memory leak in SWIG_SDLVideo / SDL_Surface / SWIG_SDLImage

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

Hi Patric,

I didn't even have a chance to look at it properly and you've already 
solved it! 

Thanks so much for the detailed look you had at this.  Will go over it, 
it looks good.  The only problem is we have to change the way SWIG 
auto-generates the code.  For now I'll just patch the file as you've 
shown.  Eventually I'll need to figure out how to get SWIG to generate 
the wrapper code with that change in place.  We don't really generate 
the wrapper code often so it should be alright.  The only time would be 
when making the wrappers for a new OS or if it was required for some 
other reason like a new SDL version, etc....

Will let you know when its in.

Cheers,
-Ivan/

Patric Rufflar wrote:

>Hi Ivan, hi all,
>
>After playing around with the patched source I realized that
>there is another critical memory problem.
>
>At first, please have a look at the jni definition inside SWIG_SDLVideoJNI
>
>public final static native void SDL_FreeSurface(long jarg1);
>public final static native void delete_SDL_Surface(long jarg1);
>public final static native long new_SDL_Surface();
>
>
>The first method, SDL_FreeSurface(), is ok. It does what it name 
>suggests, it calls the corresponding native SDL method.
>
>The other two methods seems to me dummy native methods for 
>contructors/destructors.  The original SDL_surface.c does not contain 
>any constructors/destructors, because it's pure c.
>So I think these jni calls do nothing.
>
>
>Ok, let's now have a look at SDLSurface.freeSurface() which will be 
>called on its finalization.
>
>     public void freeSurface() throws SDLException {
>	SWIG_SDLVideo.SDL_FreeSurface(swigSurface);
>	swigSurface = null;
>	pixelData   = null;
>     }
>
>As we can see, the real surface of the embedded SDL_Surface proxy object 
>will be freed. But what happens if there are other valid references to 
>this proxy object? It's memory pointer to the sdl surface is not valid 
>anymore, freeing this object may end up in a core dump.
>
>Now let's have a look at SDL_Surface finalization method, delete():
>
>   public void delete() {
>     if(swigCPtr != 0 && swigCMemOwn) {
>       swigCMemOwn = false;
>       SWIG_SDLVideoJNI.delete_SDL_Surface(swigCPtr);
>     }
>     swigCPtr = 0;
>   }
>
>This method calls the jni delete method, which is only a dummy. The real 
>memory is not freed. This is the memory leak.
>
>Because some SDL_Surface objects seem to be created without referenced 
>by a SDLSurface. But I have to admit that I cannot give an example in 
>the source right now.
>
>To fix these two problems, I suggest the following solution:
>
>Changes at SDLSurface:
>     public void freeSurface() throws SDLException {
>	SWIG_SDLVideo.SDL_FreeSurface(swigSurface); <<--delete this line
>	swigSurface = null;
>	pixelData   = null;
>     }
>
>
>Changes at SDL_Surface:
>   public void delete() {
>     if(swigCPtr != 0 && swigCMemOwn) {
>       SWIG_SDLVideo.SDL_FreeSurface(this); // As you can see, 		 
>//delete_SDL_Surface() has been replaced by the correct method.
>       swigCMemOwn = false;
>     }
>     swigCPtr = 0;
>   }
>
>
>This patch will ensure, that the finalization of the proxy object 
>(SDLSurface) will lead to freeing the surface not it's sdljava interface 
>to it (SDL_Surface). This fixed the memory problems in my application ;)
>
>To find those problems I am creating / deleting many surfaces in my 
>application. And It seems that there is at least another (less lossy) 
>memory leak which eats up memory.
>
>And I also want to add that the methods of SWIG_SDLImage seems to be 
>affected by the memory leak which I previously described, too.
>
>
>Best Regards
>Patric Rufflar
>
>
>
>Ivan Z. Ganza schrieb:
>  
>
>>Greetings,
>>
>>Thanks for finding this.  Yes this is a serious problem.
>>
>>I need to do figure out how to get SWIG to set that flag to true instead 
>>of false, then the leak should be eleminated.  The code there is 
>>auto-generated by SWIG from the .i files.  In the worst case I can 
>>manually run a script after to post-process that stuff and fix it that 
>>way.  Either way it will be fixed.
>>
>>Cheers,
>>-Ivan/
>>
>>Jesper Juul / Soup Games wrote:
>>
>>    
>>
>>>I wanted to post about this for a long time - I agre there is a leak 
>>>. So far I've worked around it by wrapping all Surfaces in a custom 
>>>object that calls dispose() in the finalizer.
>>>
>>>
>>>-Jesper
>>>
>>> 
>>>
>>>      
>>>
>>>>I was wondering a long time why my application needs more and more RAM.
>>>>I took a while to track down a possible memory leak.
>>>>It seems to be located in sdljava.x.swig.SWIG_SDLVideo .
>>>>
>>>>The following methods seems to be affected:
>>>>SDL_ConvertSurface(), SDL_DisplayFormat() and SDL_DisplayFormatAlpha()
>>>>
>>>>I am not sure at the moment, but maybe other methods have the same problem:
>>>>SDL_SetVideoMode(), SDL_CreateRGBSurface(), SWIG_SDL_LoadBMP(),
>>>>SWIG_SDL_CreateRGBSurfaceFrom()
>>>>
>>>>Please have a look at the last line of all methods:
>>>>return (cPtr == 0) ? null : new SDL_Surface(cPtr, false);
>>>>
>>>>As you can easily see, false indicates that the new surface cannot free
>>>>the memory because some other surface seems to also use it. But this is
>>>>not true, the surface has just been created, no other surface does own
>>>>this memory area.
>>>>
>>>>So this bug should be fixed when setting the second argument of the
>>>>surface constructors to true.
>>>>
>>>>Ivan, would you please verify the problem?
>>>>Thank you.
>>>>
>>>>Best Regards,
>>>>Patric
>>>>   
>>>>
>>>>        
>>>>
>>>-------------------------------------------------------------------------
>>>Using Tomcat but need to do more? Need to support web services, security?
>>>Get stuff done quickly with pre-integrated technology to make your job easier
>>>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>>_______________________________________________
>>>sdljava-users mailing list
>>>sdl...@li...
>>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>> 
>>>
>>>      
>>>
>>-------------------------------------------------------------------------
>>Using Tomcat but need to do more? Need to support web services, security?
>>Get stuff done quickly with pre-integrated technology to make your job easier
>>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>_______________________________________________
>>sdljava-users mailing list
>>sdl...@li...
>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>
>>
>>    
>>
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys -- and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>  
>

Re: [sdljava-users] Possible memory leak in SWIG_SDLVideo / SDL_Surface / SWIG_SDLImage

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

Hi Ivan, hi all,

After playing around with the patched source I realized that
there is another critical memory problem.

At first, please have a look at the jni definition inside SWIG_SDLVideoJNI

public final static native void SDL_FreeSurface(long jarg1);
public final static native void delete_SDL_Surface(long jarg1);
public final static native long new_SDL_Surface();


The first method, SDL_FreeSurface(), is ok. It does what it name 
suggests, it calls the corresponding native SDL method.

The other two methods seems to me dummy native methods for 
contructors/destructors.  The original SDL_surface.c does not contain 
any constructors/destructors, because it's pure c.
So I think these jni calls do nothing.


Ok, let's now have a look at SDLSurface.freeSurface() which will be 
called on its finalization.

     public void freeSurface() throws SDLException {
	SWIG_SDLVideo.SDL_FreeSurface(swigSurface);
	swigSurface = null;
	pixelData   = null;
     }

As we can see, the real surface of the embedded SDL_Surface proxy object 
will be freed. But what happens if there are other valid references to 
this proxy object? It's memory pointer to the sdl surface is not valid 
anymore, freeing this object may end up in a core dump.

Now let's have a look at SDL_Surface finalization method, delete():

   public void delete() {
     if(swigCPtr != 0 && swigCMemOwn) {
       swigCMemOwn = false;
       SWIG_SDLVideoJNI.delete_SDL_Surface(swigCPtr);
     }
     swigCPtr = 0;
   }

This method calls the jni delete method, which is only a dummy. The real 
memory is not freed. This is the memory leak.

Because some SDL_Surface objects seem to be created without referenced 
by a SDLSurface. But I have to admit that I cannot give an example in 
the source right now.

To fix these two problems, I suggest the following solution:

Changes at SDLSurface:
     public void freeSurface() throws SDLException {
	SWIG_SDLVideo.SDL_FreeSurface(swigSurface); <<--delete this line
	swigSurface = null;
	pixelData   = null;
     }


Changes at SDL_Surface:
   public void delete() {
     if(swigCPtr != 0 && swigCMemOwn) {
       SWIG_SDLVideo.SDL_FreeSurface(this); // As you can see, 		 
//delete_SDL_Surface() has been replaced by the correct method.
       swigCMemOwn = false;
     }
     swigCPtr = 0;
   }


This patch will ensure, that the finalization of the proxy object 
(SDLSurface) will lead to freeing the surface not it's sdljava interface 
to it (SDL_Surface). This fixed the memory problems in my application ;)

To find those problems I am creating / deleting many surfaces in my 
application. And It seems that there is at least another (less lossy) 
memory leak which eats up memory.

And I also want to add that the methods of SWIG_SDLImage seems to be 
affected by the memory leak which I previously described, too.


Best Regards
Patric Rufflar



Ivan Z. Ganza schrieb:
> Greetings,
> 
> Thanks for finding this.  Yes this is a serious problem.
> 
> I need to do figure out how to get SWIG to set that flag to true instead 
> of false, then the leak should be eleminated.  The code there is 
> auto-generated by SWIG from the .i files.  In the worst case I can 
> manually run a script after to post-process that stuff and fix it that 
> way.  Either way it will be fixed.
> 
> Cheers,
> -Ivan/
> 
> Jesper Juul / Soup Games wrote:
> 
>> I wanted to post about this for a long time - I agre there is a leak 
>> . So far I've worked around it by wrapping all Surfaces in a custom 
>> object that calls dispose() in the finalizer.
>>
>>
>> -Jesper
>>
>>  
>>
>>> I was wondering a long time why my application needs more and more RAM.
>>> I took a while to track down a possible memory leak.
>>> It seems to be located in sdljava.x.swig.SWIG_SDLVideo .
>>>
>>> The following methods seems to be affected:
>>> SDL_ConvertSurface(), SDL_DisplayFormat() and SDL_DisplayFormatAlpha()
>>>
>>> I am not sure at the moment, but maybe other methods have the same problem:
>>> SDL_SetVideoMode(), SDL_CreateRGBSurface(), SWIG_SDL_LoadBMP(),
>>> SWIG_SDL_CreateRGBSurfaceFrom()
>>>
>>> Please have a look at the last line of all methods:
>>> return (cPtr == 0) ? null : new SDL_Surface(cPtr, false);
>>>
>>> As you can easily see, false indicates that the new surface cannot free
>>> the memory because some other surface seems to also use it. But this is
>>> not true, the surface has just been created, no other surface does own
>>> this memory area.
>>>
>>> So this bug should be fixed when setting the second argument of the
>>> surface constructors to true.
>>>
>>> Ivan, would you please verify the problem?
>>> Thank you.
>>>
>>> Best Regards,
>>> Patric
>>>    
>>>
>>
>> -------------------------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services, security?
>> Get stuff done quickly with pre-integrated technology to make your job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> sdljava-users mailing list
>> sdl...@li...
>> https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>  
>>
> 
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users
> 
> 

Re: [sdljava-users] Possible memory leak in SWIG_SDLVideo

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

Greetings,

Thanks for finding this.  Yes this is a serious problem.

I need to do figure out how to get SWIG to set that flag to true instead 
of false, then the leak should be eleminated.  The code there is 
auto-generated by SWIG from the .i files.  In the worst case I can 
manually run a script after to post-process that stuff and fix it that 
way.  Either way it will be fixed.

Cheers,
-Ivan/

Jesper Juul / Soup Games wrote:

>I wanted to post about this for a long time - I agre there is a leak 
>. So far I've worked around it by wrapping all Surfaces in a custom 
>object that calls dispose() in the finalizer.
>
>
>-Jesper
>
>  
>
>>I was wondering a long time why my application needs more and more RAM.
>>I took a while to track down a possible memory leak.
>>It seems to be located in sdljava.x.swig.SWIG_SDLVideo .
>>
>>The following methods seems to be affected:
>>SDL_ConvertSurface(), SDL_DisplayFormat() and SDL_DisplayFormatAlpha()
>>
>>I am not sure at the moment, but maybe other methods have the same problem:
>>SDL_SetVideoMode(), SDL_CreateRGBSurface(), SWIG_SDL_LoadBMP(),
>>SWIG_SDL_CreateRGBSurfaceFrom()
>>
>>Please have a look at the last line of all methods:
>>return (cPtr == 0) ? null : new SDL_Surface(cPtr, false);
>>
>>As you can easily see, false indicates that the new surface cannot free
>>the memory because some other surface seems to also use it. But this is
>>not true, the surface has just been created, no other surface does own
>>this memory area.
>>
>>So this bug should be fixed when setting the second argument of the
>>surface constructors to true.
>>
>>Ivan, would you please verify the problem?
>>Thank you.
>>
>>Best Regards,
>>Patric
>>    
>>
>
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>  
>

Re: [sdljava-users] Possible memory leak in SWIG_SDLVideo

[Jesper J. / S. G. <je...@so...>]

I wanted to post about this for a long time - I agre there is a leak 
. So far I've worked around it by wrapping all Surfaces in a custom 
object that calls dispose() in the finalizer.


-Jesper

>I was wondering a long time why my application needs more and more RAM.
>I took a while to track down a possible memory leak.
>It seems to be located in sdljava.x.swig.SWIG_SDLVideo .
>
>The following methods seems to be affected:
>SDL_ConvertSurface(), SDL_DisplayFormat() and SDL_DisplayFormatAlpha()
>
>I am not sure at the moment, but maybe other methods have the same problem:
>SDL_SetVideoMode(), SDL_CreateRGBSurface(), SWIG_SDL_LoadBMP(),
>SWIG_SDL_CreateRGBSurfaceFrom()
>
>Please have a look at the last line of all methods:
>return (cPtr == 0) ? null : new SDL_Surface(cPtr, false);
>
>As you can easily see, false indicates that the new surface cannot free
>the memory because some other surface seems to also use it. But this is
>not true, the surface has just been created, no other surface does own
>this memory area.
>
>So this bug should be fixed when setting the second argument of the
>surface constructors to true.
>
>Ivan, would you please verify the problem?
>Thank you.
>
>Best Regards,
>Patric

[sdljava-users] Possible memory leak in SWIG_SDLVideo

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

Hello everyone, Hello Ivan,

I was wondering a long time why my application needs more and more RAM. 
I took a while to track down a possible memory leak.
It seems to be located in sdljava.x.swig.SWIG_SDLVideo .

The following methods seems to be affected:
SDL_ConvertSurface(), SDL_DisplayFormat() and SDL_DisplayFormatAlpha()

I am not sure at the moment, but maybe other methods have the same problem:
SDL_SetVideoMode(), SDL_CreateRGBSurface(), SWIG_SDL_LoadBMP(), 
SWIG_SDL_CreateRGBSurfaceFrom()

Please have a look at the last line of all methods:
return (cPtr == 0) ? null : new SDL_Surface(cPtr, false);

As you can easily see, false indicates that the new surface cannot free 
the memory because some other surface seems to also use it. But this is 
not true, the surface has just been created, no other surface does own 
this memory area.

So this bug should be fixed when setting the second argument of the 
surface constructors to true.

Ivan, would you please verify the problem?
Thank you.

Best Regards,
Patric

Re: [sdljava-users] New Release?

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

Greetings,

I'm not sure as to when a new release would be made.  I could make a new 
release right now, but I could only provide linux binaries.  Currently I 
don't have a windows system setup for development.  I wonder if even a 
source only release would be alright for peoples purposes?

As to how many people are using sdljava:  A few to be sure; but not many 
either.  I would appreciate any suggestions for how to make the project 
more public.  Really could use help with the windows side of things, 
testings on windows, the build env, etc...

-Ivan/

Patric wrote:

>Hello Ivan,
>
>I'm glad you are back. When do you expect a new release for sdljava?
>
>And btw, what do you think how many developers are using sdljava? Maybe you should think about making the project more public (using sourceforge newnews, other open source sites) to gain more contributors.
>
>Best Regards,
>Patric
>
>The following message was sent by "Ivan Z. Ganza" <iva...@ya...> on Wed, 13 Sep 2006 20:19:23 -0400.
>
>  
>
>>Greetings,
>>
>>Sorry for the delay!  I finally got off my but and got everything 
>>working on my system so I can develop again.  Everything is 64 bit for 
>>
>>now though as I didn't get a 32 chroot working yet, but alas, that will 
>>
>>have to wait for another time.
>>
>>I have applied the fix below to HEAD.
>>
>>Cheers,
>>-Ivan/
>>
>>Guillaume Legris wrote:
>>
>>    
>>
>>>Hi,
>>>
>>>First thanks for SDLJava. It's a great library !
>>>
>>>There is a bug in the file SDLVideo.i (revision 1.32 from CVS HEAD)  inside 
>>>      
>>>
>>>the method  SWIG_SetPixelData32(SDL_Surface *surface, int data[]) :
>>>
>>>  Uint32 * pixelData = (Uint32*)&data;
>>>
>>>has to be replaced by:
>>>
>>>  Uint32 * pixelData = (Uint32*)data;
>>>
>>>(same thing for SWIG_GetPixelData32 method I guess...But not tested)
>>>
>>>I need this method because I have to draw an ARGB int array in a SDL 
>>>surface.
>>>
>>>At First, I tried createRGBSurfaceFrom(int pixels[], ...). But JNI code 
>>>      
>>>
>>>seems not working (JVM crash)
>>>I also tried SDLSurface.getPixelData() which returns a direct byte buffer 
>>>      
>>>
>>. 
>>    
>>
>>>It works fine on x86 Sun JVM but not (JVM crashed) with Jamvm + Classpath 
>>>      
>>>
>>>0.92 on ARM which is my target.
>>>
>>>A little suggestion: I think that createRGBSurfaceFrom could be easily 
>>>      
>>>
>>>implemented in Java only with help of createRGBSurface() and getPixelData() 
>>>      
>>>
>>>(or SWIG_SetPixelData32) methods.
>>>
>>>Regards,
>>>Guillaume Legris
>>>
>>>
>>>
>>>-------------------------------------------------------------------------
>>>Using Tomcat but need to do more? Need to support web services, security?
>>>Get stuff done quickly with pre-integrated technology to make your job 
>>>      
>>>
>>easier
>>    
>>
>>>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>>_______________________________________________
>>>sdljava-users mailing list
>>>sdl...@li...
>>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>> 
>>>
>>>      
>>>
>>-------------------------------------------------------------------------
>>Using Tomcat but need to do more? Need to support web services, security?
>>Get stuff done quickly with pre-integrated technology to make your job 
>>easier
>>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>_______________________________________________
>>sdljava-users mailing list
>>sdl...@li...
>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>
>>
>>    
>>
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>  
>