Colors and Pixels

I’m currently making a program doing very simple 2D graphics. I used to in the past, for pixel by pixel animation, use an array of integers and a MemoryImageSource. The problem with this is the fact that you can’t grab the Graphics object of this image, and then use it to draw images, or fill circles normally. BufferedImages supposively allow you to do this now, but every attempt I’ve made at using it’s ability to draw pixels directly has resulted in EXTREMELY low frame rates.

Also, another problem is the fact that the Color object NEEDS to be used when drawing a Oval, or a Rectangle. If I’m creating 30 Color Objects a second, the garbage collector goes nuts and my frame-rates drop too. The only solution I’ve found is to make all of the Colors, and store them before drawing to the screen. What I would like to do is to change the Color using an Integer value, and draw using the same Color object, rather than creating a new one every time.

-Jason Thomas.

Decompiling the Color class we see that the value member has package access. Perhaps you could subclass Color so that you can directly access this member variable. This would only help you if you don’t want to use floats for the different components of your colors. value is an int containing ARGB.

Of course your new class would have to be in the java.awt package. Just an idea.

It seems very strange that the class doesn’t have any setter methods. One would think that is an obvious need.

#2:
You could subclass Color and override the regular behavior; I think the critical methods are all public – check the source to be sure. I think your current solution is probably the best course though.

edit: I was looking at the source and I thought value was private. I’ll try to remember to check that again later :smiley: until then, listen to zparticle


package java.awt;

import java.awt.color.ColorSpace;
import java.awt.geom.AffineTransform;
import java.awt.geom.Rectangle2D;
import java.awt.image.ColorModel;
import java.io.Serializable;

public class Color
    implements Paint, Serializable
{

    public static final Color white = new Color(255, 255, 255);
    public static final Color lightGray = new Color(192, 192, 192);
    public static final Color gray = new Color(128, 128, 128);
    public static final Color darkGray = new Color(64, 64, 64);
    public static final Color black = new Color(0, 0, 0);
    public static final Color red = new Color(255, 0, 0);
    public static final Color pink = new Color(255, 175, 175);
    public static final Color orange = new Color(255, 200, 0);
    public static final Color yellow = new Color(255, 255, 0);
    public static final Color green = new Color(0, 255, 0);
    public static final Color magenta = new Color(255, 0, 255);
    public static final Color cyan = new Color(0, 255, 255);
    public static final Color blue = new Color(0, 0, 255);
    private transient long pData;
    int value;
    private float frgbvalue[];
    private float fvalue[];
    private float falpha;
    private ColorSpace cs;
    private static final long serialVersionUID = 0x1a51783108f3375L;
    private static final double FACTOR = 0.69999999999999996D;
    private PaintContext theContext;
.
.
.
}

Damn forum software wouldn’t take the entire code listing.

Alright, you can’t add any new classes to java.awt, because the ClassLoader forbids it. Soooo… I completely re-impleneted the Color class by extending it, and then overriding ALL of it’s private methods and values.

Thanks for the help.

Now , if anybody knows how to do pixel by pixel manipulation efficiently with a buffered Image, I’d really like to see the code.

-Jason Thomas.

Also, setColor internally checks the refference of the Color object you’re giving it, against the Color Object it already has. So in order to change the MutableColor on the fly, you need to call setColor on one of the static Colors, and then set the Color to your MutableColor object.

-Jason Thomas.

I’m just curious, but how many different colors are you working with?

All Colors. IIn most programming languages, you can simply send three integers representing red green and blue. This entire Color Object thing isn’t a bad idea, because it relates to ColorSpaces, but it’s inefficient for Game Programming, or any kind of real-time animation. Yes, I could buffer the Colors I’m using, I’d rather not be limited to doing that, however.

-Jason Thomas.

I seriously doubt that even 100 Color objects per second would affect your framerate too much. Color object is not that expensive to create/dispose of.

As for manipulating the BuffferedImage pixels direclty - indeed, it won’t be too efficient as you’d have to have several method calls per pixel. Try to avoid direct pixel manipulation, since it’d really affect our ability to accelerate this image for you (that is, put it into video memory).

Or, you can just be a bad boy and get the DataBuffer from it, and get the approriate arraytype ( int[] from DataBufferInt etc), and fiddle along at your leasure.
Like:

BufferedImage bi = frame.getGraphicsConfiguration().createCompatibleImage(xs, ys, Transparency.OPAQUE);
WritableRaster wr = bi.getRaster();
DataBufferInt db = (DataBufferInt)wr.getDataBuffer();
int[] pixels = db.getData();

Ofcourse, you should check the type of the DataBuffer, check the ColorModel to see how the data is stored etc etc.

Maybe this thread helps:

http://www.java-gaming.org/cgi-bin/JGOForums/YaBB.cgi?board=2D;action=display;num=1036556890