Skip to main content

Blitting a Java 2D Buffer Image to win32 native window

1 reply [Last post]
evanherc
Offline
Joined: 2008-07-09

Apologies if this is a duplicate, the mailing list message didn't seem to come through.

May seem like a strange question but I have an extensive Java2D based renderer which currently paints in a backbuffer and is then flipped onto a AWT Panel using VolatileImage. Works fine but I'm now faced with very specific requirement that I need to draw the graphics onto a native win32 window component, meaning I still want all my paint logic to happen in java but the actual display needs to be in a native windows app. Unfortunately embedding an AWT component is not really an option because it presents all kind of issues with multiple event threads etc. (Events still all need to be handled by the native component).

I looked at native AWT but it seems to do exactly the reverse of what I need ;-) How would I go about achieving this with the least amount of overhead and not embed an AWT component inside the win32 window ? All the solutions I came up with involved either copying pixels or converting into a different image format .. which you simply don't want to happen for each frame. I'm not afraid of JNI or using other types of buffers in Java.

Any suggestions would be highly appreciated,
Erik

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Dmitri Trembovetski

Hi Erik,

java2d@JAVADESKTOP.ORG wrote:
> Apologies if this is a duplicate, the mailing list message didn't seem to come through.
>
> May seem like a strange question but I have an extensive Java2D based renderer which currently paints in a backbuffer and is then flipped onto a AWT Panel using VolatileImage. Works fine but I'm now faced with very specific requirement that I need to draw the graphics onto a native win32 window component, meaning I still want all my paint logic to happen in java but the actual display needs to be in a native windows app. Unfortunately embedding an AWT component is not really an option because it presents all kind of issues with multiple event threads etc. (Events still all need to be handled by the native component).
>
> I looked at native AWT but it seems to do exactly the reverse of what I need ;-) How would I go about achieving this with the least amount of overhead and not embed an AWT component inside the win32 window ? All the solutions I came up with involved either copying pixels or converting into a different image format .. which you simply don't want to happen for each frame. I'm not afraid of JNI or using other types of buffers in Java.

If you create you back buffer (it will probably have to be a
BufferedImage) with the desired format you won't
have to do the image format conversion.

So you'd render to a BI in Java, get the data buffer array,
get the pointer to data on the native level, then use
GDI (for example), to create a bitmap, copy the pixels into
that bitmap (in some cases you may be able to just create
a header and point to the pixels instead of copying), and
then BitBlt that bitmap to your window.

You can take a look at the java's GDI blit loop which
pretty much does just that.
http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/08f77c507252/src/windows/n...

Thanks,
Dmitri

>
> Any suggestions would be highly appreciated,
> Erik
> [Message sent by forum member 'evanherc' (evanherc)]
>
> http://forums.java.net/jive/thread.jspa?messageID=285409
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".