Applet images caching

[besbello]

Hi all,
I hope I'm posting this question to the correct group. I'm using an
applet to show a recorded sequence of .jpeg images. Users has the
posibility to use 'play', 'stop' or 'rewind' buttons. But when they use
'rewind', applet requests again all images from server. I want to use
cache to avoid it, is it possible? (I want to run applet under JDK 1.1
- MSJVM)
Thanks,

 

[Oliver Wong]

Hi all,
I hope I'm posting this question to the correct group. I'm using an
applet to show a recorded sequence of .jpeg images. Users has the
posibility to use 'play', 'stop' or 'rewind' buttons. But when they use
'rewind', applet requests again all images from server. I want to use
cache to avoid it, is it possible? (I want to run applet under JDK 1.1
- MSJVM)

Yes, it's possible. Just keep a reference to your image objects, and
re-use them instead of redownloading them.

- Oliver

 

[besbello]

Hi,
I hope I've understood your reply. I'm actually using an array Image[]
to implement a buffer (because I need to show images at a faster rate
than applet get images from server). But my problem is that this
buffer's size is limited (each image takes up 70Ks, and if buffer is
too long, I get a java.lang.OutOfMemoryError-Java heap space). So I'm
looking for a way to use browser cache or other solution to avoid this
memory error. I'm using getToolkit().getImage() with a MediaTracker to
get images.
Perhaps I've not understood what you mean with "reference to image
objects", isn't it something similar to my buffer? If it's so, memory
limit is the problem.
Thanks a lot,

Oliver Wong ha escrito:

 

[Andrew T.]

..I'm actually using an array Image[]
to implement a buffer (because I need to show images at a faster rate
than applet get images from server). But my problem is that this
buffer's size is limited (each image takes up 70Ks, and if buffer is
too long, I get a java.lang.OutOfMemoryError-Java heap space).

Interestingly, the JVM caches images that are obtained using
the usual Toolkit methods (the ones most mentioned in tutorials,
and the ones generally called by AWT and Swing components).

Whether that works 'as expected' in a browser's JVM is another
matter.

Image slideshows generally suffer the OOME problem you are
referring to. As a way around those problems, you can abandon
the general methods of obtaining an image, and instead use your
own methods to get the bytes themselves - this puts caching
back in your control.

But there's a 'gotcha' here. An Image object takes up far more
bytes of memory than the associated bytes[] stored in the file,
especially with JPEG's.

The way around it is to store the original bytes you load for each
image into a byte[][] array, then stamp each set of bytes out to a
single Image using Toolkit.creatImage(byte[]) at the moment
you need to display it.

I wrote a slideshow that held references to 2 Images (the
current image, as well as the 'next' - about to be displayed),
as well as a byte[][] arary of the bytes of all the images.
This allowed me to run slideshows of 100's of images within
the standard 64Meg JVM, and the caching problem was entirely
solved.

HTH

Andrew T.

 

[besbello]

Ok, only two questions:

- How much space would I save using byte[][] instead of Image
object?
- Could you tell me the way to achieve this transformation, please?
(Remember it
would be perfect if I can use the applet over MSJVM).

Thanks a lot

Andrew T. ha escrito:

..I'm actually using an array Image[]
to implement a buffer (because I need to show images at a faster rate
than applet get images from server). But my problem is that this
buffer's size is limited (each image takes up 70Ks, and if buffer is
too long, I get a java.lang.OutOfMemoryError-Java heap space).

Interestingly, the JVM caches images that are obtained using
the usual Toolkit methods (the ones most mentioned in tutorials,
and the ones generally called by AWT and Swing components).

Whether that works 'as expected' in a browser's JVM is another
matter.

Image slideshows generally suffer the OOME problem you are
referring to. As a way around those problems, you can abandon
the general methods of obtaining an image, and instead use your
own methods to get the bytes themselves - this puts caching
back in your control.

But there's a 'gotcha' here. An Image object takes up far more
bytes of memory than the associated bytes[] stored in the file,
especially with JPEG's.

The way around it is to store the original bytes you load for each
image into a byte[][] array, then stamp each set of bytes out to a
single Image using Toolkit.creatImage(byte[]) at the moment
you need to display it.

I wrote a slideshow that held references to 2 Images (the
current image, as well as the 'next' - about to be displayed),
as well as a byte[][] arary of the bytes of all the images.
This allowed me to run slideshows of 100's of images within
the standard 64Meg JVM, and the caching problem was entirely
solved.

HTH

Andrew T.

 

[Andrew T.]

Ok, only two questions:

One request. Please post in-line, as I do, and trim earlier text
that is not needed.

- How much space would I save using byte[][] instead of Image
object?

(shrugs) 'It depends'. I never measured it exactly because
it depends on, for example, the JPEG compression level.

I got the impression the factor was at least 4-1 on an
'average' selection of compressed and uncompressed
images that might be lying about your disk. But don't
quote me - the major part of solving the problem was to
ensure the images were not cached within the JVM -
once that was solved, most of the memory errors
disappeared and I though much less about it.

- Could you tell me the way to achieve this transformation, please?
Sure..

(Remember it
would be perfect if I can use the applet over MSJVM).

Ugghhh.. that obsolete, insecure, non-compliant plug-in again?

OK. You're in luck that the way is so basic.. but I am
taking a shortcut here, I have some code at the SaverBeans
project that does what I described. You can find it here..
<https://screensavers.dev.java.net/s...st?folderID=1393&expandFolder=1393&folderID=0>
the 'SliderSaver' zip file does just what I described.

I am afraid the slideshow overall is a bit 'overkill' for
a simple example, but if you can understand that code,
it will show you the basic technique (which should work
for 1.1, from memory).

HTH

Andrew T.