functions where generating the garbage and taking the time.
HTH,
Hugh
>X-Original-To: [EMAIL PROTECTED]
>Delivered-To: [EMAIL PROTECTED]
>Delivered-To: [EMAIL PROTECTED]
>Subject: Re: [JAVA3D] Java3D & Garbage Collection
>To: [EMAIL PROTECTED]
>
>PLEASE! Take a look at th
PLEASE! Take a look at this thread!
Maybe you can help
Thanks,
Giuseppe
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
Excuse me! ". generated by Buffered Images..."
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] an
I managed to bypass TextureLoader using this:
**
java.io.File myfile = new java.io.File( myPath );
java.awt.image.BufferedImage myBufImage = null;
try { myBufImage = javax.imageio.ImageIO.read( myFile );}
catch (java.io.IOExcepti
ment I'm
not in the state to investigate them.
Cheers,
Florin
-Ursprüngliche Nachricht-
Von: Giuseppe Fontana [mailto:[EMAIL PROTECTED]]
Gesendet: Donnerstag, 20. Februar 2003 21:34
An: [EMAIL PROTECTED]
Betreff: Re: [JAVA3D] Java3D & Garbage Collection
Thank you all
John Wright wrote:
I suppose I should point out I don't know if Justin or Alan or someone
else is the actual author of the code. Sorry, I tend to just credit
Justin because I deal with him more and he is the most public person
supporting and running j3d.org.
In this case it is Justin. But a fa
I suppose I should point out I don't know if Justin or Alan or someone
else is the actual author of the code. Sorry, I tend to just credit
Justin because I deal with him more and he is the most public person
supporting and running j3d.org.
- John
Alan Hudson wrote:
>
> John Wright wrote:
> > Giu
Giuseppe,
Try starting at:
http://code.j3d.org
and specifically:
http://code.j3d.org/javadoc/org/j3d/texture/package-summary.html
I found it while digging through Justin's cache code before I decided to
write my own cache code.
- John Wright
Starfire Research
Giuseppe Fontana wrote:
>
> Joh
John Wright wrote:
Giuseppe,
Justin has written code that loads images for textures without using
TextureLoader. I believe one of the main reasons Justin wrote his code
is specifically to avoid this issue of TextureLoader creating multiple
copies of the same image. It does require the images ar
John,
where can I find that code?
By the way ... I tested StarfireExt 2.20... very good work
It's really 3-4 time faster!
Giuseppe
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message
Giuseppe,
Justin has written code that loads images for textures without using
TextureLoader. I believe one of the main reasons Justin wrote his code
is specifically to avoid this issue of TextureLoader creating multiple
copies of the same image. It does require the images are powers of two
thou
Thank you all for the assistance!
I executed the environment using:
" java -Xrunhprof:heap=all,file= etc... myClass"
If I'm not wrong I guess the problem is about a lot of retained image objects.
The largest is generated at trace 14522 by java3D texture loader, into the process
stimulus of a Beha
Giuseppe,
I notice that you already got an answer to the first part of your question.
If you look at the 'stack trace' column of the heavily-used objects, you can
tally this up with one of the earlier 'TRACE' entries, so you can see what was
on the stack when the objects were allocated, and thus
IL PROTECTED]>
Sent: Wednesday, February 19, 2003 1:33 PM
Subject: Re: [JAVA3D] Java3D & Garbage Collection
> On Wed, 19 Feb 2003 16:26:40 +, Rob Nugent <[EMAIL PROTECTED]> wrote:
>
> >Giuseppe,
> >
> >You could try running your app with 'java -Xrunhprof:hea
On Wed, 19 Feb 2003 16:26:40 +, Rob Nugent <[EMAIL PROTECTED]> wrote:
>Giuseppe,
>
>You could try running your app with 'java -Xrunhprof:heap=sites ...'
>
>When your app terminates, you can inspect the resultant hprof file and look at
>the SITES section to see what objects are in your heap. Th
Giuseppe,
You could try running your app with 'java -Xrunhprof:heap=sites ...'
When your app terminates, you can inspect the resultant hprof file and look at
the SITES section to see what objects are in your heap. This might give you some
clues.
Rob
[EMAIL PROTECTED] wrote:
I'm developing a 3D
I'm developing a 3D environment using Java3D for academical purposes.
This environment performs ( at runtime ):
* a lot of texture loading/updating
* picking behavior
* BranchGroups attaching/detaching
I experience heavy memory leaks (15-20 mb) when I rebuild the environment at runtime.
17 matches
Mail list logo
