yes, you are correct. textures are proccessed in vram as a collection of pixels. at this stage the only releveant factor in terms of performance is the dimensions of the map. (for 512x512 that would be exactly 1.5mb per) and the source file size is not taken into consideration...however in order to read and transfer resources from disk into vram there are a number of possible bottlenecks. primariy hard drive read speed. but also there is an overhead on much slower (than vram) system ram to perform the operation....and then there is the cost in proccessor time required to actually fetch the file, decode it and send it to the gpu's texture cache in it's bitmap form. (pci-e bandwidth is not a problem we can do anything about anyway so let's just ignore it)
this last point is what this method is meant to attack.... but you say hey wait a second...proccessors are so fast nowadays! .indeed, they are. but there are also faster, less expensive methods of decoding png data.
-"ok, fine. but what is this so called 'faster' method you speak of?"
suprisingly simple. 8 bit palettes are decoded 3 times faster than 24 bit ones.
-"and what about transparency?"
alpha values are indexed as another color in the color table so there's no "full" alpha channel to proccess.
after that it's up to your gpu to do the rest of the work.
note: (and another silly dialogue)
- "right, so what's the catch?"
Well, I've got these fine leather jackets.....
nah just kidding
as we all know, Java is a buggy beast. so make sure your image palette has at least 128 entries to avoid an old and obscure bug in J2SE involving pngplugin and elderberries (long story...don't ask)
but i don't think minecraft even use that. at least i've never had a problem with opimized textures, but it's worth noting