Whatever... The image was not being drawn because the alpha
channel was 0x00. Initializing the alpha channel to 0xff allowed
us to see the image. I don't have a lot of energy for a big discussion
about this.
But this whole experiment still leads me back to ask for a way to
decode an image directly into an integer array like I first asked.
Something like pixels = imageReader.decodeFileBytesToIntegerArray(...)
But all I seem to get from you is "...rewrite the applet..." Ok.
I think I'm done.
Jim Graham wrote:
The MemoryImageSource relies on the ColorModel to define whether or not
the data contains an alpha channel. If you use one of the MIS
constructors that does not take a ColorModel object then those
constructors are specifically specified to use the default RGB
ColorModel as defined by the ColorModel.getRGBdefault() method which
specifies 8 bits of alpha.
I'm not sure what you mean when you say that it "means it's transparent
to [...] BufferStrategy" since that object doesn't deal with pixel
storage formats...
...jim
Ken Warner wrote:
Maybe it doesn't mean the BufferedImage is transparent but
0x00 in the alpha channel of a pixels means it's transparent to the
MemoryImageSource and BufferStrategy.
Jim Graham wrote:
The 3byte databuffer has no storage available for an alpha value.
When the data is loaded into the TYPE_INT_RGB BufferedImage there is
no alpha stored there since that is an opaque type. More
specifically, if you load one of the integers from the underlying
int[] pixel array of such an image the upper 8 bits are undefined and
should be ignored - if those bits are 0 then that does not mean that
the pixel is transparent, and if they contain a 0xff value then that
is just a lucky coincidence as those bits are not explicitly tracked
or initialized by any code that deals with that image type...
...jim
Ken Warner wrote:
I just thought of something. What is the alpha channel set to
when the BufferedImage is created and the databuffer is extracted?
If the alpha channel is 0, that would explain a lot. That means the
image is transparent. There's two stages of rendering. The first
stage
only does nearest neighbor interpolation. The second stage does a
bi-cubic
interpolation and I explicitly initialize the alpha channel to 0xff
to make
the image not transparent.
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".
===========================================================================
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".
