Mr. Schachter,
Thanks for the nice description of what your team has done with image
loading.
I believe the reason to compress the files when writing to disk (and
decompressing when reading) is partly that disk I/O is relatively slow
and hence with a fast CPU, reading a smaller file and decompressing it
is actually faster than just straight reading a large file. Of course
this is going to depend on your hardware configuration (fast drives and
slow CPU is a different story). Gut feel is that it depends also on the
form of compression, some methods can be decompressed faster than
others.
- John Wright
Starfire Research
David Schachter wrote:
>
> Mr. Yazel--
>
> We did much of what you suggest and in some ways more. I'll describe the approach,
>in the hopes that it might be useful for someone else. It's worth noting that we
>started by inspecting and understanding the source code for Sun's TextureLoader.
>
> We preprocess all the images (video frames) to have power-of-two dimensions and
>write them out into individual files as (uncompressed) arrays of bytes. At run time,
>we read them back into memory, directly into place in a BufferedImage that's created
>once and reused. For each image, we read a nine byte header that describes the size
>of the image and then read the entire pixel array in a single read. As each image in
>a sequence is the same size, we were able to reuse objects and thus avoid the
>overhead of frequently allocating and deallocating objects and large pixel arrays.
>
> The goal was to eliminate as much run-time processing as possible, by avoiding the
>CPU cost of image decompression, image resizing, and memory allocation. We verified
>the memory allocation goal by using the Runtime.getRuntime().totalMemory() and
>Runtime.getRuntime().freeMemory() methods. We verified the speedup created by
>avoiding decompression and image resizing by making time measurements.
>
> A substantial additional speedup came from having a separate thread read each file
>just before the file is needed ("prereading"). This ensures the file is in the OS
>file system buffer. To minimize the chance of synchronization bugs, we don't use the
>result of that thread's work. However, we did simulate the potential performance
>impact of having the prereader thread pass its results to the main code. There was
>almost no improvement. In fact, this simulation suggested that there was essentially
>nothing more we could do to speed up painting.
>
> A difference between our approach and your suggestion is that we eschewed the use of
>any on-disk compression. Disk space and bandwidth is cheap, while CPU time is
>expensive. Some graphics chips support a compressed format for textures and it might
>be interesting if Java3D had a way to support this. I don't have data to support or
>reject this conjecture.
>
> No performance difference was observed using byReference, with or without the yUp
>flag. We didn't pursue that path further because no one on the team is smart enough
>to understand byReference.
>
> I'd be interested in the reasoning behind your suggestions about the nio package,
>the use of ZIP compression, and reading individual scan lines rather than entire
>images.
>
> Apparently Mr. Couch, Mr. Yazel, and my company have had to implement our own image
>handling code for performance reasons. Perhaps Sun could consider a
>performance-oriented interface between image handling and Java3D in a future release.
>I'm sure my company would be pleased to participate.
>
> -- David Schachter
>
> At 08:54 AM 2/20/2002 -0500, Yazel, David J. wrote:
> >No problem.
> >
> >There really are a lot of options for texture management. It is possible to
> >make your texture loading extremely fast and extremly memory efficient. But
> >it is difficult to dop that and stay "standard". If you use ImageIO or the
> >various standard codecs then generally you will see a lot of extra memory
> >used when it builds the image. I am not sure why developers of these
> >libraries are so unconcerned about memory usage, especially considering the
> >size of images. I would have thought that the imageio package would have
> >the tightest, fastest most memory efficient image loaders around. They sure
> >worked on it long enough.
> >
> >Anyway, if you don't care about disk space, and you are not pulling these
> >images over the wire, you can do the followng trick. Use JDK 1.4. Write
> >out the buffered image, its dimensions and its format (so basically an
> >array[][] of int and a type int, and 2 ints for the dimensions) to a
> >ZipStream into a file.
> >
> >To load it fast:
> >
> >1. memory map the file.
> >2. create a byte array stream
> >3. wrap it with a zip decoder
> >4. Read in the header (dimensions and type) and create a buffered image
> >5. read back your data by scan lines using readBytes(fully) and the nio byte
> >-> int buffers
> >6. Put each scan line into the buffered array
> >
> >It will be fast, and it will use very little additional memory. The
> >compressed stream will not produce the same sort of compression as PNG or
> >JPG, but it will load very fast.
> >
> >Dave Yazel
> >
> >
> >-----Original Message-----
> >From: Tom Lanning [mailto:[EMAIL PROTECTED]]
> >Sent: Wednesday, February 20, 2002 8:36 AM
> >To: [EMAIL PROTECTED]
> >Subject: Re: [JAVA3D] Textures and memory consumption
> >
> >
> > Thanks for the suggestions.
> >
> > 1. I am not doing any mipmapping. I leave that to the underlying system.
> >
> > 2. I am measuring memory use before and after garbage collection.
> >However, I am concerned about the peak size of the application. (Some
> >memory is available after items go out of scope/reach.)
> >
> > 3. I have been looking at the source for the loader. I passed along some
> >of these comments so that whoever is maintaining the loader might include
> >the ".dispose()" and ".flush()" calls to help keep memory use under control.
> >
> > 4. :-( I am beginning to think that is what I will need to do. However,
> >I am not sure if much of the extra memory is being consumed there. I
> >suspect that a lot of it is used in the initial image loading.
> >
> > Again, thanks for the response.
> >
> >----- Original Message -----
> >From: "Yazel, David J." <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Sent: Wednesday, February 20, 2002 8:22 AM
> >Subject: Re: [JAVA3D] Textures and memory consumption
> >
> >
> >| Couple of things:
> >|
> >| 1. If you are mipmapping then there will be increased memory usage.
> >| 2. Stupid suggestions, but make sure you are measuring memory after you have
> >| garbage collected.
> >| 3. The source for the loader is available un the util jar if you want to improve
>it.
> >| 4. If you are doing all that work, why not skip the texture loader and skip
> >| right to building the texture and image components yourself? All it does
> >| for you is make mipmaps, and not very good ones at a that.
> >|
> >| Dave Yazel
> >|
> >| -----Original Message-----
> >| From: Tom Lanning [mailto:[EMAIL PROTECTED]]
> >| Sent: Wednesday, February 20, 2002 8:04 AM
> >| To: [EMAIL PROTECTED]
> >| Subject: [JAVA3D] Textures and memory consumption
> >|
> >| I am developing an application that uses a lot of large (512x512) textures.
> >| If I use something like TextureLoader and let it load the images I end up
> >| with consuming over 300M of memory ... much more than the size of the
> >| textures. I can reduce the memory by loading the images myself,
> >| transforming them to a "power of 2" size, dispose the graphics context,
> >| flush the image, and pass a BufferedImage to the TextureLoader constructor.
> >| It sounds to me that TextureLoader is not disposing the Graphics2D and not
> >| flushing any images it loads. However, even with all this extra stuff, the
> >| size of the application is much larger than it should be. Is there anything
> >| else I can do to reduce the memory consumption without reducing the texture
> >| size?
> >|
> >| I am using the DirectX release version of J3D and JDK1.3.
>
> --
> [EMAIL PROTECTED] (email is preferred)
> Voice: +1 415 948 6769
> Fax: +1 801 640 2154
> Mail: 1220 La Playa, #301, San Francisco, CA 94122-1077
>
> ===========================================================================
> 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] and include in the body of the message "help".
===========================================================================
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] and include in the body of the message "help".
