[2689] in java-interest
Re: Async image loading
daemon@ATHENA.MIT.EDU (Jim Graham)
Tue Oct 10 21:27:07 1995
Date: Tue, 10 Oct 1995 15:36:53 -0700
From: flar@bendenweyr.Eng.Sun.COM (Jim Graham)
To: java-interest-digest@java.Eng.Sun.COM, julie@world.std.com
Hi Julie,
> We appreciate the posting of the media tracker example but I still find it
> odd that the image must be rendered to be fetched. Isn't this an excessive
> use of resources? I'm guessing this is the best alternative, being as it
> comes from inside Sun, but I still long for the previous beta's behavior and
> functionality.
I was a little too brief in my previous explanation. In particular,
the image data will load whenever you execute a method that requires
some information about the image. If you execute getWidth() and
getHeight() these methods will also induce the image to start loading.
Note that there was no "previous beta". Were you referring to the
Alpha releases?
One of the problems with the Alpha releases was that we had to have
enough memory around to hold an image in memory before you could do
anything with it. Also, once we constructed a screen representation of
that image, we no longer had the original image data around any more to
do things like filter it, scale it, or print it. The new APIs allow us
to be much more conservative on memory utilization for loading and
rendering images. In the Beta APIs I can do a getImage() on a file
that is a 10Megabyte GIF which expands to 24 million pixels. I can
then render that image in my applet at 100 x 100 and everything works
great. Under Alpha, I had to explicitly run HotJava with a 32 Megabyte
address space and then my machine would page incessantly for 5 minutes
while it filled that 32 meg with pixel data that it would eventually
discard. This is a rather extreme case, but when memory gets tight,
smaller images could end up causing the same problems. Witness the
fact that the Alpha ImageMap demo will tend to fail if you've been
running HotJava for more than a couple of hours since memory
fragmentation would prevent allocating a buffer large enough to store
all of the pixel data (and that's only a 522x486 image).
There were potentially a number of solutions to these problems, but the
basic solution that I came up with that seems to provide a tremendous
amount of robustness at the expense of a more asynchronous twist to the
APIs is the current architecture in which Image data is delivered
asynchronously (with various caching tricks to help out) rather than
simply viewing images as big monolithic buckets of pixels.
We also went with delayed realization of images so that we could more
quickly format HTML pages and instantiate applets. If every applet
that we init() needs to do lengthy download operations then we will end
up wasting lots of time in page layout and applet startup that the user
might wish to use in reading the surrounding text. In general, we
would like to have the goal of throwing as few roadblocks in the way of
completely instantiating an HTML page as we can for higher performance
web browsing...
One particular fallout of this system is that we don't make any
assumptions about what particular size you plan to render the image
at. If we made the default assumption and automatically loaded and
produced a full-size 1:1 scale version of the image when you first
create it then we would end up preventing you from dealing with any
images that are bigger than our existing contiguous heap space, or
causing some really nasty performance hits when you tried. Instead, we
wait for you to indicate what size you want to render the image at
before we start downloading it. On the other hand, if you ask for the
width or height and you haven't executed a drawImage call yet, we
download anyway and hope that our internal caching of the pixels will
allow us to produce the desired screen representation when you
eventually get to rendering it.
One modification that I've toyed with is automatically starting the
download when the applet does the getImage and automatically make an
assumption and produce a 1:1 version of the image without waiting for
the Applet to tell us what size to produce. Unfortunately, this will
have the net effect of starting up a bunch of background threads which
will compete with the threads that are trying to complete the
instantiation and layout of the HTML page. I think things will be much
better overall if we have applets wait until they are "start()"ed
before they start their media downloads.
The MediaTracker class gives some explicit control over all of this
back to the Applet and we are working on phasing in some new APIs that
allow a Component (i.e. an Applet) to explicitly request the
construction of a particular size of an image to fix this problem that
you can't declare what size you want without rendering it. Until then,
the version of the MediaTracker that I posted on my home page will work
within the existing APIs (if you look at it, it renders the images to a
1x1 off screen image in order to kick off the construction of the
image...)
...jim
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
