Render bitmaps really fast

[Thomas Richter]

Hi folks,

what's the recommended method to render bitmaps really fast in Java?

Here's the problem at hand: The given program (in Java) receives about
ten times a second a bitmap thru a network - here thru a CORBA interface,
but that's unimportant - and has to render the bitmaps on a screen as fast
as possible. To avoid delays due to garbage collection, the design should
be as static as possible: The bits received from the connection should be
rendered to the screen as direct and straight as possible.

If this is of any help, data arrives in chunks of 64x64 pixels that can
be rendered individually.

Second problem: We're receiving several streams of the above kind, but
have to render them on top of each other with transparency. What would be
the best method for this kind of problem?


Greetings,
Thomas

 

[Thomas Weidenfeller]

Hi folks,

what's the recommended method to render bitmaps really fast in Java?

Here's the problem at hand: The given program (in Java) receives about
ten times a second a bitmap thru a network

Ten frames per second? Almost a movie? Sounds like a job for the media
framework: http://java.sun.com/products/java-media/jmf/

If you want to do it yourself, VolatileImage is probably the fastest
image to get. Or you change the whole application to full-screen
exclusive mode.

- here thru a CORBA interface,

You use CORBA and you are worried about performance, or you are worried
about performance because you use CORBA? I can understand the later.

Second problem: We're receiving several streams of the above kind, but
have to render them on top of each other with transparency. What would be
the best method for this kind of problem?

Maybe an own ImageProducer used in an own Image class. And then a
drawImage() to draw that data onto a VolatileImage.

/Thomas

 

[Chris Smith]

If you want to do it yourself, VolatileImage is probably the fastest
image to get. Or you change the whole application to full-screen
exclusive mode.

I'm not so sure about VolatileImage. The point of VolatileImage is that
the image can be stored in memory on the video card, so that drawing it
to the visible screen can be done without transferring the image data
through the PCI (or ISA, or AGP, or whatever) bus. That tactic makes a
lot of sense when you've got *one* image that you may need to draw a
large number of times; you store it in video memory once, and then the
video card can be intructed to draw it without repeating image data.

In this case, though, once a frame is received and drawn once, that
frame's data is useless. Using VolatileImage doesn't eliminate the need
to transfer the image data to the video card in the first place, and
really provides benefit only when the image data is repeatedly useful,
such as if it's an icon or a static piece of a component that may need
to be redrawn at least occasionally. If an image is messed up in the
OP's case, it's probably best to just leave it and wait for the next
image frame to come in.

That said, JMF and full-screen mode are both worth trying (the latter
only if it meets requirements, of course).

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Thomas Richter]

Hi,

Ten frames per second? Almost a movie? Sounds like a job for the media
framework: http://java.sun.com/products/java-media/jmf/

Ok, I'll have a look there.

If you want to do it yourself, VolatileImage is probably the fastest
image to get. Or you change the whole application to full-screen
exclusive mode.

You use CORBA and you are worried about performance, or you are worried
about performance because you use CORBA? I can understand the later.

The CORBA part is currently the fast part about it. The data comes
'sort of compressed' and the CORBA thruput is not the limiting factor.

Maybe an own ImageProducer used in an own Image class. And then a
drawImage() to draw that data onto a VolatileImage.

Ok, I'll have a look into the JMF and the VolatileImage.

Thanks for the hints, appreciated!

So long,
Thomas

 

[Knute Johnson]

Hi,




Ok, I'll have a look there.




The CORBA part is currently the fast part about it. The data comes
'sort of compressed' and the CORBA thruput is not the limiting factor.




Ok, I'll have a look into the JMF and the VolatileImage.

Thanks for the hints, appreciated!

So long,
Thomas

I don't think VolatileImage is going to help you as Chris said. The
images are small enough, even with several (how many is that?) streams
and 10 images per second that they could easily be made into
BufferedImages and drawn on the screen without having problems running
into each other. JMF will do video or image streams but that sounds
like more overhead than you really need. I find JMF very difficult to
use but that could just be me .

 

[Roedy Green]

Ten frames per second? Almost a movie? Sounds like a job for the media
framework: http://java.sun.com/products/java-media/jmf/

If you want to do it yourself, VolatileImage is probably the fastest
image to get.

With a simple JPeg stream over the net I get at most about 4 frames a
second. Over a lan perhaps 10.

 

[Thomas Weidenfeller]

I'm not so sure about VolatileImage. The point of VolatileImage is that
the image can be stored in memory on the video card, so that drawing it
to the visible screen can be done without transferring the image data
through the PCI (or ISA, or AGP, or whatever) bus. That tactic makes a
lot of sense when you've got *one* image that you may need to draw a
large number of times; you store it in video memory once, and then the
video card can be intructed to draw it without repeating image data.

Yes, you are right. It is more of a WORM type image.

/Thomas