Thanks for you input Chet,

Well one problem is that I need to do a few per-pixel operations.
Anyways as it seems like most of the java2d functions are accelerated
inside the JVM, it could be faster to simply draw a line of length 1, or
is it? Also my custom class built on ImageProducers is almost 50% faster
than pure java2d (though I still don't know how to load the images
quickly), so I don't think it's worth to use java2d if it isn't a lot
faster, the biggest problem with performance seem to be rotation of an
image which is **slow** compared to what you can do with C/asm. The
reason why my own class is faster, is because I can combine effects in
ways that aren't possible without accessing the pure image buffer and
knowing what I'm doing...

However, my biggest problem is with browser support. As only netscape 6
seems to directly support java2d (well I'm unable to test with IE, as
I'm using linux, freebsd and solaris, so I don't know). I can only hope
JVMs are going to be like any plugin, ie. the browser can inform the
user that he/she needs to update his/her JVM. Now it seems like the only
people that actually update their JVMs are developers... and that's not
a big market for a company :)

Hearing that jdk1.4 is going to support hardware acceleration is really
cool. I hope T&L hardware is going to be used with transformations. I
don't know the internal architecture of the java2d pipeline (I'd love to
find some good info), but if it performs all rendering in one shot when
calling drawImage, the implementation in hardware can't be difficult
(atleast this would make image rotating faster :)).

Also I'm wondering how big is the performance difference between C and
Java, when accessing buffers directly, is it like 1:20-30? And one more
thing, could it be possible to in a future release of java map objects
to another, like being able to map an int array to a byte array so that
they would both "point" to the same thing ie. changing the int at
address n would be the same thing as accessing the byte at address 4 *
n. Thus it would be possible to write pure data into something while
still using the routines provided by java to manipulate this object. Of
course this could come with some locking issues, and it could be
"unjavaish" or something...

ps. could anyone recommend any book on the internal working of the JVM,
there's enough information about the language on the internet, but I
haven't seen any good papers on the JVM...

- Edvard Fagerholm

Chet Haase wrote:
>
> Edward,
>
> The BufferedImage object in Java2D was created for easier access to the
> pixels of an image, so I think you might find it easier to use that
> API for what you are doing rather than the ImageProducer approach.
> To get the array of pixel data from a BufferedImage, you could do
> something like:
>                 // createImage(w,h) doesn't guarantee a BufferedImage
>                 // but it works that way for now.  There are other
>                 // ways to create a BufferedImage directly, but this
>                 // will do for this example
>         BufferedImage bImg = (BufferedImage)createImage(w, h);
>         Raster raster = bImg.getRaster();
>         DataBuffer dBuff = raster.getDataBuffer();
> (I'm glossing over some of the details here, but these are the
> main objects that you would play with to set pixel data).
>
> Having said this, if your interest is in gaming and fast graphics,
> you might try to find a way to avoid playing with the pixels directly;
> if you could use higher-level API to set your pixel data that would
> be easier for the API to accelerate.  For example, if you need
> to draw a line, it would be better to call bImg.getGraphics().drawLine()
> than to draw that line yourself (no matter how fast your line-drawing
> algorithm is).  This is somewhat true for the current jdk release,
> but will be even more the case going forward.
> As of the next release (jdk1.4), we are enabling the use of hardware
> acceleration for offscreen images.  But if you request access to the
> pixel data directly, we have to punt and disable acceleration for
> that image.
>
> I hope this helps.
>
> Chet.

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

Reply via email to