jav...@javadesktop.org wrote:
- let us know what image formats you are seeing in the loaded image and
which Reader is loading it so we can consider adding loops that deal
with that format more directly (or modifying our "format detection" code
to recognize it if there is something amiss with our classifications).
We do already have support for a fair number of "binary" image formats
so I'm curious as to what the exact specifics of the format are and why
they fail to trigger our existing optimized binary format loops. This
should probably be done through the bug tracking system to keep records
of the issue...
Your comment above seem to indicate that you have optimized loops for reading binary images directly in compatible BufferedImages. Is that correct?
There are 2 issues here:
- What do you have to do to use a 1-bit image loaded from disk efficiently
- How can you efficiently convert it into an efficient format if just
using the loaded 1-bit image is slow
The first question basically depends on the image reader using only
methods that avoid tainting the image so that the returned BufferedImage
can be managed. I'm not sure why that is not happening without further
investigation, but maybe Dmitri or Chris know what is going on there off
the top of their heads.
As to the second question, when I looked at the support we had it was
pretty sketchy in the Blit support department (see my previous message
where I listed the available loops and then looked at what got used by
the drawImage call). We have routines for rendering to 1-bit images,
but we only have a couple of conversion routines for blitting from 1-bit
to another format (to ARGB and back to be specific). So, there is room
for improvement there (both in avoiding the very general
OpaqueCopyAnyToArgb loop and possibly in adding a few more Blit
converters for the format).
If yes, then my simple most important question would be:
What is the method to read a binary image from a file fast and have a
compatible BI in memory? My tests indicate that saving a RGB BI in the BMP
format will do the trick, but here is the catch:
For now it seems you have to do some conversion and it looks like you've
finally arrived at a decent way of doing that short of "not having to do
it in the first place".
I think it's worth filing a bug on the conversion process (really a
drawImage should have done the trick without too much fuss, but you had
to work around that).
We should probably also investigate why the 1-bit image is not being
managed so that you don't need any conversion at all. Is it a bug in
the reader, or in our image management (caching) code?
In any case, you shouldn't have to resort to BMP to work around this -
we're so close, let's look at closing the gap on a 1-bit TIFF.
So, instead of trying to find out what is the best way to convert, it would be
better to know what is optimized and how to use it! I understand that in the
general case, the average jdk developer does not need to know what you optimize
and what not, but it would be a great idea to publicize this info (even
unofficial, i understand that you wouldn't want to write this in stone).
I think my previous message mentioned some tools for programmers to get
a glimpse into what we've targetted with direct implementations vs. what
we do with "general workaround code"...
...jim
===========================================================================
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
lists...@java.sun.com and include in the body of the message "help".
