[EMAIL PROTECTED] wrote:
Thanks Chris.
I knew I'd forget something from the original post.
Graphics card: nvidia geforce 6600
Driver: nvidia 97.55
OS: Linux 2.6.20.
java version "1.6.0_02-ea" (happens on 1.6.0-b105 as well).
Image: 720x576, 32bpp, rgb format. - chosen to test dvd resolution rendering.
Thanks for the info.
Yep, this is exactly how I'm painting.
- copy video data into (unmanaged) BufferedImage
- copy BufferedImage into VolatileImage
- scale VolatileImage to the destination (with BILINEAR enabled)
And that works really well. It just seemed a bit non-obvious that I would have
to go through the extra steps.
It's probably the best you can do for now (with the OpenGL-based
pipeline in JDK 6). Even if we figured out a better way to implement it
internally, it probably wouldn't be a whole lot faster than what I
outlined above.
However, it kind of pains me to see so much extra copying of pixels
going on, which is usually a killer for video applications. What I
outlined above is about the best you can do with our current Java2D
architecture, but if you're serious about performance, you might want to
think about having an alternate codepath that uses JOGL when available.
If using OpenGL directly, you can bypass a lot of the copying involved
in the approach you're using above. For example, I'd recommend:
- use pixel buffer object (PBO) extension to lock video buffer memory
- decode video frame directly into that memory chunk
- upload PBO to texture memory using glTexSubImage2D()
- copy texture to hardware backbuffer (if using a heavyweight
component) or the Swing backbuffer (via GLJPanel, for example)
This approach cuts out at least three different copy operations; not
sure what your performance requirements are though, and whether it's
necessary. This is getting a bit off-topic, but if you're interested,
you could probably get some help from the folks on the JOGL forum over
at javagaming.org...
i.e. I naively thought that java2d would have figured out to do the equivalent of
BufferedImage->VolatileImage before scaling the image, if the image was
unmanaged, and the desination was managed.
We unfortunately don't have those smarts in our image management code at
the moment, but I'll make a note of it for a possible enhancement at a
later date. The tricky part is to know how much VRAM to spend for
intermediate use (for isolated cases like this, it's not such a big
deal, but for more complicated cases, we have to make sure we don't
start creating lots of intermediate VRAM surfaces haphazardly). Anyway,
it's something to think about.
Thanks,
Chris
[Message sent by forum member 'wmeissner' (wmeissner)]
http://forums.java.net/jive/thread.jspa?messageID=216710
===========================================================================
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".
