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?
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=6205557
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 operate on the pixel
> data buffer directly, Java 2D engine can't use hardware acceleration.
So, my question is : Is there a method can produce pixel based
> animation and use hardware acceleration instead of 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".
