When I run the applets from appletviewer I see 16 numbers printed on the console for the BI version but only 8 printed for the PG version - hopefully there isn't a typo causing the loads to be done twice?

                        ...jim

Ken Warner wrote:
Hi Jim,

I'm not communicating the step by step procedure for the projection
I guess.  It's not like you describe.  There is no massaged data.  It's
just a pixel map that I take a portion of and calculate a gnomic projection.

If I had a white board I could draw a diagram that explains everything.

It's a realtime (sort of) projection.

Anyway, here's the two different versions of the applet I promised.  One
uses PixelGrabber the other uses BufferedImage.  This is the performace
problem I'm seeing.

I always take the blame for something like this until proven otherwise.

So I must be doing something wrong but the code is so simple I just
don't see where.

http://pancyl.com/BufferedImage.htm

http://pancyl.com/PixelGrabber.htm

PixelGrabber works ok for a prototype.
BufferedImage is a mystery yet.

You have the source to the class where
the problem is.  If you have time to take a look at makeBuffereImage()
and maybe you will see something I don't.

Ken

Jim Graham wrote:
Hi Ken,

Do you really need to rewrite it all the way through? For example, the massaged data (that has been run through the panoramic projection) could be stored in integer format - it's just the code that reads a pixel out of the source tiles that needs to change, but any intermediate storage and the final storage that you use could be integer-based.

I'd have to see the conversion code to make any suggestions beyond these guesses...

        ...jim

Ken Warner wrote:

I'll try that.

Using bi = reader.read(0,param);
PanTile Testbed
1813
1031
1001
982
941
981
1002
971

Using bi = reader.read(0) <-default reader
PanTile Testbed
1081
601
291
330
261
270
300
280

Using PixelGrabber etc.
PanTile Testbed
1432
1221
1272
1112
1141
1081
1101
1092

Clearly the default reader is faster by a lot -- except the data is
not in a format I can use in the current version.  The current version
of the apple is only expected to download one image so I wasn't much
concerned with that piece of code.

A version loading tiles is another thing.  But the code would have to
be re-written all the way through to the final paint loop. Because I use
integer arrays everywhere.

Maybe it  would be worth the effort if I could be sure that the final
performance was really going to be much faster than it is now.  The
rendering would have to be significantly faster to make the re-write
really worth the effort.

And while I have been resistent to the idea of using BufferedImages --
I will do anything to make my applet faster.  But given that the
applet is stable and fairly well tuned using integer arrays, I'm not
likely to re-write it using the three byte databuffer to save 800ms
per 1meg tile.  Tiles will most likely be even smaller.

*And the performance slowdown is after I get the pixels from the databuffer.*

After the int [] pixels is assigned to, all the other code remains the same
except I see this unexplained slow down in user interaction.

If I can figure that problem out (with your help) then it might be worth the
re-write.

[stuff deleted]

===========================================================================
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