Hello.
I have a problematic request.
I have to make some activeX that should display its own things and… images given from the outside.
I’m asked to be able to blit on my surface some bitmaps that are already on the graphic adapter, without transfering them to memory.
(i make the assumption that the destination bitmap will also be in graphic adapter, of course, and that the operation is accelerated )
Is that possible, as far as you know?
Hm. I’m not sure I understand your request.
Which of those “surfaces” is a Java surface (if any)?
Or is this unrelated to java completely?
Dmitri
This is java related, somewhat.
I’m asked to make a lib that would take the display surface of a directshow graph, draw a bunch of things using java2d and then display the whole on an other surface.
What i’m looking for is a way to have java2d draw on that surface using an accelerated BufferedImage.
To be true, i believe that it is not possible and should not be possible (for architectural reasons), but… i have to ask anyway.
Yeah, I don’t think that could be done.
If it was possible, it would have to be something through JAWT
(I’m guessing you knew that) . Look
around, may be someone has done something like that.
For example:
http://www.cs.kuleuven.ac.be/~barta/links/jni-jawt.pdf
Dmitri
Yes, i had fiddled with jawt some time ago… i try to avoid doing things like that as much as possible… 8)
Anyway, i have an other question on that topic.
What if i create a bufferedimage from a dataBuffer (created from native code) that uses a natively allocated buffer, which buffer resides in AGP memory zone?
If i blit that bufferedimage onto an accelerated bufferedimage (let it be volatile or automatic, if that is important), is there something done on your side to test for various things and eventually avoid some steps, like transfers or whatever?
I’m afraid it is a dumb question, i’m not much aware of the mechanisms that you use. ??? :-[
Unfortunately in this case the resulting BufferedImage will not be
managed since we won’t have control over the contents of the
data buffer (so we could not guarantee that the cached copy is
correct).
Also, since we will not have blit loops for such custom image,
copying it around will be rather slow (via get/setPixel), and it will also
happen though system memory. It will be horrendously slow.
You could do your own “managing” by caching this image in VolatileImage.
So you create your image with custom databuffer, and cache it in
VolatileImage, updating the cached copy when your source image is
updated. This will only be worth it if you’re not updating the source image
too often.
We are actually considering adding support for DataBuffers with contents
outside of java heap, in, say, NIO buffers (which may point to an AGP memory)
for the next release.
But we didn’t have too many requests so far, I believe.
Thanks,
Dmitri
Oh, i’ts worse than i expected, but i should have expected that. 
Content of image buffer ought to change at 50 or 60 hz. I think that it should be quite manageable to transfer a buffer to volatile at that rate, even for HD res images…
Count me in for a request about NIO databuffer support. that would surely help a lot in my world of mixed-origin media handling.