Image Backgrounds - .gif

Question

Hi. Im making an rpg, and while trying to add the image of the person ontop, i noticed that, unlike on websites, the background of black isnt transparent. Could someone please help. Is there a color that java reconizes as see-through for a .gif?
Thanx in advanced,
ME :D

Answer 1

Would a png reduce the time it takes to repaint?
Not per se, no. Images are decoded when loaded so the source is pretty much irrelevant.
My brother said being able to look at the hex value and not the .grabPixels() array would reduce the time it take to repaint. Is this true?
I'm not sure I follow. What are you doing? You don't need to grab pixels to repaint, are you manipulating the image directly in between paint cycles? If so then you can expect operations to be quite slow.
4000 x 3500 image cut in 2. Would that reduce repaint time?
Possibly. Are you using transforms to render with? If not then you can't hope to render all that on a screen so there'd probably be no harm in tiling it.
Right now what is happening is u can see each picture repaint itself.
I suspect what you have, since you're using GIFs (which are palletised) is an image which has a data transfer type different to that used by the graphics device.
Via GraphicsEnvironment and GraphicsDevice you can get GraphicsConfiguration and query its ColorModel and then its transfer type. In most cases this will be an integer type but it's best to check.
Then, from the BufferedImage you've created, get its ColorModel and the transfer type. You'll probably find with a GIF-sourced image that it's a byte type.
If the two transfer types are different then pasting the image is a costly operation: what you need to do is use the GraphicsContext to create a compatible image, then render your old image into it, and dispose of the old one.
That's a fairly undesirable step to have to go through - it'll obviosusly take a bit of processor time for an image the size of yours and there's the memory overhead of having it in memory twice as well (even though the initial image will be only a quarter the size of the compatible one, if it uses bytes instead of ints). So one thing you can do is store your image as a true-color PNG instead of a GIF - there's nothing magic about this, but what it does mean is that on decoding it you will end up with a color model and transfer type which is integer-based and will render quickly for anyone using a true-color display (which is most people).
You're doing this in an applet and an integer-based image of that size is going to cause you massive problems with heap space. You've got 96Mb to play with and that image will eat 56Mb of it. If you're having to copy a byte image to it then that's going to require an extra 14Mb overhead.
I would strongly question the wisdom of using a 4000x3500 image in an applet. What are you using it for? Can you find an alternative means of rendering the image or parts of it? - eg if a lot of it is plain-colour then can you break it into parts which only cover the non-plain sections? if there are repetitions in the image can you re-use tiles?
Oh hang on, it'd help if I checked that applet link...
WHOA! Yeah - there's no need at all for a huge image like that! You only have two background tiles, a green one and a blue one - use a data structure to lay out the tiles, eg if you wanted four green squares surrounded by a ring of blue squares you might do it like this,
int[][] map =
    { 0, 0, 0, 0 },
    { 0, 1, 1, 0 },
    { 0, 1, 1, 0 },
    { 0, 0, 0, 0 }
}...though you'd be better off sticking the values in a text file and parsing it to create the map.
Hope that all helps.