For this image, my laptop spends 97% of the CPU on
tdata = raster.getDataElements(startX,i,width,1,tdata);
in BufferedImage.zoom().
This is not unreasonable, but it just spends a lot longer at this on what appears to be a smaller image.
I don’t get it. That was a lot of work to come up with nothing. Fortunately, I’m giving an exam right now. What else is there to do but profile VASSAL.
I seem to have discovered the problem. If the map doesn’t have an alpha layer, my machine screeches to a halt. It will unfreeze after about 60 seconds, but while it’s zooming, my desktop is dead. I can switch to a terminal via CTRL-ALT-F1, but X is just frozen (or at least Gnome is). Could this be a byte alignment issue?
Bizarre. I have no idea. All I can really say at this point is that the
problem is not in our code, it’s some combination of the JVM, X, and the
video drivers in your kernel.
This is the first problem I’ve noticed and it took a long time for me to notice it.
I’m not a graphics expert, but I suspect a byte-alignment issue. I’m assuming that RGB is only 24 bits and that the native methods on my machine are stupid. I should try OpenJDK again and see what happens. It may be the interface between Java and X and not X itself. For example, zooming in GIMP causes no problems at all.
I’ve never encountered a true 24-bit storage format, for exactly the reason
you give: byte alignment is a pain, not worth the 25% savings in size over
using 4 bytes for each pixel but leaving one unused.
I think it might be that X doesn’t even have a true 24-bit format.