Hi Jim,

You raise some interesting points.  The reason I used Toolkit was because of 
the simplicity of the code that I needed to write.  I wrote an early version of 
my applet using ImageIO and BufferedImage.  The code ended up being  pretty 
complicated.  Right now I use Toolkit; grab the pixels; flush the image and do 
all my image manipulations on the raw one dimensional byte array returned by 
the PixelGrabber.

I have quite a lot of functionality wrapped up in a pretty small package. Less 
than 20k and it has it's own nearest neighbor; bilinear; and bicubic 
interpolators all built into the projection from cylindrical to rectilinear 
viewport.

Take a look:

http://pancyl.com/

And I'm so far along in my development cycle that recoding for ImageIO (which 
is really good stuf - no slight intended) that recoding for ImageIO would set 
me back a month or more.

The thing is, PixelGrabber implements the ImageConsumer interface.  And the 
doc's say an InterruptedException is supposed to be raised -- I quote the doc's 
in my previous message -- but it's not.  That's the problem.  If it was -- I'd 
be home free.  The thread I do the PixelGrabbing from is just suspended.  All 
other threads are still up and running.

To be clear -- the image is downloaded; the image has been decoded by Toolkit; 
when I try to grab the pixels, my thread is suspended by ImageFetcher.

The way I fetch the image from the server is I just download it as a byte array 
then give it to Toolkit to decode.  Really simple code. It all works with 
reasonable speed considering the usual constraints on downloading a 1 meg file 
over the internet.

Another handicap is that I don't have the source to

class sun.awt.image.ImageFetcher extends java.lang.Thread

It's one of those mystery classes.  If I had source, a workaround might pop out 
at me.

Do you have the source to sun.awt.image.ImageFetcher or know where I can get 
it???

Ken

Jim Graham wrote:
Hi Ken,

QUESTION: does anyone have an idea of how to handle this situation?

Shouldn't ImageFetcher.run() throw something?  Like an OutOfMemoryError
or something so that grabPixels() can throw an InterruptedException like
the documentation says it will???


The ImageFetcher should capture any errors and pass on an ERROR
condition to all ImageConsumers.  Is that happening here?

My suggestion would be to use ImageIO instead of the Toolkit image
facility for a couple of reasons:

- Getting pixels via PixelGrabber goes through some really indirect
mechanisms that should be slower than ImageIO (YMMV as we haven't
necessarily benchmarked your particular usage, but it would be a safe bet).

- ImageIO does the image loading in your own thread so you can catch
such errors and deal with them with a lot less fuss.

- ImageIO will deliver you one single copy of the image - when you use
PixelGrabber and Toolkit images then you run the risk of the Toolkit
image storing the pixels itself and then also feeding them to your
PixelGrabber which would double the amount of memory needed and the
memory used for the Toolkit image is harder to control since it is
managed by another mechanism (hint: Image.flush() should get rid of it,
but be careful not to trigger it to reload the image data again in the
future).  To give you an idea - image.getWidth(canvas) is enough to
trigger the Toolkit image to load and store its own version of the image.

- Also, if the Toolkit image is loading its own version of the image in
addition to the data it delivers to your PixelGrabber, that is even more
of a performance loss.

- (BTW, PixelGrabber can get the W/H itself and create an array for you
if you use the PixelGrabber(image, 0, 0, -1, -1, forceRGB) constructor.
 That would avoid the "second copy loaded for the Toolkit image"
problem...)

Have you tried ImageIO?

                       ...jim

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-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 JAVA2D-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to