Hi Jim,
> Hi ylzhao,
>
> There are some missing details in your post that
> affect the type of
> solution that can achieve your goals. For instance,
> how often are the
> pixels updated as compared to how often the updated
> image is drawn to
> the screen? Also, what percentage of the pixels are
> modified on a
> typical update? Are the values of any of the pixels
> in the image read
> back during the modification phase?
This is my applet prototype:
=========================================================
public class Viewer extends Applet implements Runnable {
int[] idata = null; // image pixel data array
Image view = null; // viewport
int[] vdata = null; // view data array
Image offImage = null; // Offscreen rendering image
Graphics offGraphics = null; // Offscreen rendering graphics context
int offwidth = 0; // Width of the offscreen graphics
int offheight = 0; // Height of the offscreen graphics
MemoryImageSource source = null; // View is calcaulated here before dispaly
public Viewer() {
// use PixelGrabber to read pixels data into
// idata array
init();
}
public void init() {
// some init code
idata = readImagePixelData(imageFileName);
}
public void update(Graphics g) {
paint(g);
}
public void paint(Graphics g) {
// Setup offscreen rendering environmnent
offwidth = getWidth();
offheight = getHeight();
offImage = createImage(offwidth, offheight);
offGraphics = offImage.getGraphics();
vdata = new int[vwidth * vheight];
source = new MemoryImageSource(vwidth, vheight, vdata, 0, vwidth);
source.setAnimated(true);
view = createImage(source);
// read pixel data from idata and
// use some warp transform to
// extract a new view according
// to user input
transform(idata, vdata, mouse_x, mouse_y);
source.newPixels();
offGraphics.drawImage(view, 0, 0, this);
g.drawImage(offImage, 0, 0, this);
}
And, according to my mouse actions, like drag and drop on the applet, it will
call repaint and update the view.
> These issues matter since they can affect how much
> hardware acceleration
> can help you. For example, if your updates touch
> most of the pixels in
> the image, and they are read/modify/write types of
> updates, and you
> update the pixels once per frame rendered to the
> screen, then hardware
> acceleration will not give you much benefit and may
> actually hurt your
> performance as the read performance of most video
> cards is very poor
> compared to system memory.
>
> Unfortunately we are still working on a way to
> provide better
> acceleration-friendly access to the pixels of various
> image types. See
> the bug 6205557 for more information:
>
>
>
>
>
>
>
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=62
> 05557
>
> Right now if you get the DataBuffer from a Raster for
> a BufferedImage
> the image will become permanently non-acceleratable.
> This means that
> any of the relatively efficient methods on DataBuffer
> for updating the
> pixels are out of reach if you want to maintain
> acceleration. Using the
> data modification methods on the WritableRaster class
> will allow your
> image to remain acceleratable, but each time you
> modify the pixels it
> will take 2 copies to the screen before the copies
> become accelerated
> again. The reason the image is only accelerated on
> the second and
> subsequent copies is that the copy of the image data
> to the cached vram
> surface is unnecessary work if the image is always
> changing.
>
> Probably the best bet would be a solution based on an
> INT_RGB
> BufferedImage and modifying the pixels using the
> method:
>
> WritableRaster.setDataElements(x, y, int[]);
>
> ...jim
>
> > In JDK 1.5, there are BufferedImage, VolatileImage
> and BufferStrategy
> > which can be hardware accelerated. However, if
> f operate on the pixel
> > data buffer directly, Java 2D engine can't use
> e hardware acceleration.
> >
> > So, my question is : Is there a method can produce
> pixel based
> > animation and use hardware acceleration instead of
> f MemoryImageSource?
> > [Message sent by forum member 'ylzhao' (ylzhao)]
>
> ======================================================
> =====================
> To unsubscribe, send email to [EMAIL PROTECTED]
> and include in the body
> of the message "signoff JAVA2D-INTEREST". For
> general help, send email to
> [EMAIL PROTECTED] and include in the body of the
> message "help".
[Message sent by forum member 'ylzhao' (ylzhao)]
http://forums.java.net/jive/thread.jspa?messageID=135285
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
