Rendering to BufferedImage.TYPE_USHORT_565_RGB

[ad...@zitmail.uni-paderborn.de]

Hello,

I am running external SVGA displays conencted via USB that make use of 
an 565 RGB model. My current ad hoc approach is to fetch the image provided
by the StaticRenderer class and to use DrawImage to transfer image data to
an BufferedImage of the desired TYPE_USHORT_565_RGB. The data buffer 
of that image is then transfered (via jni ...) to the display. 
How can I instruct the StaticRenderer to use that BufferedImage type for
all it rendering? On the first sight I could not figure out how to achieve 
that effect without subclassing the renderer and duplicating a lot of code.

Suggestions appreciated, Adrian


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

Re: Rendering to BufferedImage.TYPE_USHORT_565_RGB

[th...@kodak.com]

Hi Adrian,

adrian@zitmail.uni-paderborn.de wrote on 11/28/2005 08:50:49 AM:

> I am running external SVGA displays conencted via USB that make use of 
> an 565 RGB model. My current ad hoc approach is to fetch the image 
provided
> by the StaticRenderer class and to use DrawImage to transfer image data 
to
> an BufferedImage of the desired TYPE_USHORT_565_RGB. The data buffer 
> of that image is then transfered (via jni ...) to the display. 

> How can I instruct the StaticRenderer to use that BufferedImage type for
> all it rendering?

   You can't with the StaticRenderer.

> On the first sight I could not figure out how to achieve 
> that effect without subclassing the renderer and duplicating a lot of 
code.

   Yes, in fact I'm not sure you can really get what you
want by just subclassing the StaticRenderer.  I would suggest looking
at the 'MacRenderer' in the current SVN codebase.  This is built around
a BufferedImage rather than the RenderedImage classes that the Static
and Dynamic Renderer's are built around.

   One word of caution, in my experience there are a number of
significant bugs in the Java2D API's for many of the Image
types.  Also since many of those image types don't have native
loops they can be much slower (10-20x) than the type selected
by Batik - in which case rendering to the 'wrong' image type
and just copying as you are currently doing is likely the
fastest option.

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org