Re: [JAVA2D] How to do pixel based animation instead of MemoryImageSource?

[Jim Graham]

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".

Re: [JAVA2D] Expanding a shape

[Jim Graham]

It depends on the performance you are looking for.  One situation where
Area can take a fairly long time to perform its calculations is when you
have curves that are very similar to each other - which would happen
here if you had an "expand distance" that was very small - say much
smaller than a pixel.  But I'm imagining that the expand distances will
typically be larger than a pixel so the calculations should be reasonable.

Try it and see (and report back on the results)...

   ...jim

Chris Nokleberg wrote:

Thanks. Actually I forgot to mention that I previously had used Area
but had some issues with performance. It seems like a bit of overkill
for this problem, since the path of interest is already calculated as
part of stroking. But I doubt there is a better solution unless I
reimplement part of BasicStroke, which I'm not going to do :-)

Thanks again,
Chris

p.s. This is for http://tonicsystems.com/products/viewer/ a free
PowerPoint viewer which uses Java2D *very* heavily. Expanding a shape
is necessary for shadowed+filled shapes with complex strokes (e.g.
dashed or triple-line)--the cast shadow is as if the shape had a solid
stroke. I assume MSFT did it that way because it was easier to
implement, which made me think there might be some tricky fast way.

On 7/17/06, Jim Graham <[EMAIL PROTECTED]> wrote:

You can use the Area class to add in the original Shape:


===
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".

Re: [JAVA2D] Expanding a shape

[Chris Nokleberg]

Thanks. Actually I forgot to mention that I previously had used Area
but had some issues with performance. It seems like a bit of overkill
for this problem, since the path of interest is already calculated as
part of stroking. But I doubt there is a better solution unless I
reimplement part of BasicStroke, which I'm not going to do :-)

Thanks again,
Chris

p.s. This is for http://tonicsystems.com/products/viewer/ a free
PowerPoint viewer which uses Java2D *very* heavily. Expanding a shape
is necessary for shadowed+filled shapes with complex strokes (e.g.
dashed or triple-line)--the cast shadow is as if the shape had a solid
stroke. I assume MSFT did it that way because it was easier to
implement, which made me think there might be some tricky fast way.

On 7/17/06, Jim Graham <[EMAIL PROTECTED]> wrote:

You can use the Area class to add in the original Shape:


===
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".

Re: [JAVA2D] Expanding a shape

[Jim Graham]

You can use the Area class to add in the original Shape:

   public Shape expandShape(Shape s, float d) {
   BasicStroke bs = new BasicStroke(d);
   // or new BasicStroke(d, CAP_ROUND, JOIN_ROUND);
   Area a = new Area(bs.createStrokedShape(s));
   a.add(new Area(s);
   return a;
   }

Note that the JOIN setting by default is MITER which may not match your
expectations for what it means to "expand the boundary of a Shape".
ROUND would result in a smoother resulting outline...

   ...jim

Chris Nokleberg wrote:

I'd like to expand the boundary of an arbitrary Shape. If I use a
BasicStroke createTransformedShape, the result is perfect except for
the resulting hole. I currently get rid of the hole by iterating over
the path, splitting the shape into multiple subshapes, and then
comparing the bounds of each subshape to find the outermost one. This
is bunch of work just to undo the unnecessary work BasicStroke has
already done, though. Any suggestions on a cleaner solution?

Thanks,
Chris

===
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".


===
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".