Copy Texture to Texture

Question

I've done 2 programs to use Shared Resources, running on SlimDX & DirectX10. One program will display the shared texture on a 3D mesh. The 2nd program will load an image as texture. So far I need to pass the shared handled everytime the texture is update from a new image.

Now, is there a way that I can initialize a fixed size shared texture (Texture2D), then everytime when I load a new image, all I need to do is load it as texture, then copy it to the existing texture. This way the shared handle would not change, and I can save some overhead of passing the shared handle. For DirectX9, I do know there a function to do just that, "StretchRectangle" but I can't find that or anything similar in DirectX10.

The intermediate format can be anything, even surface, as long as I get to update it to the shared texture.

Thanks

Aixlachapelle

Answer 1

What about CopyResource() or CopySubresourceRegion()? I don't know SlimDX, but these should work fine in native D3D10.

Loyceloyd

CopyResource doens't work. CopySubresourceRegion doesn't work as well, but I might have set it wrong. DO you have any working code? I just need the code that successfully copies the texture. I'll take care of the shared handle, thanks – Aixlachapelle

Can you be more specific about "doesn't work?" What happens? If you enable the debug layer during CreateDevice, do you get any warnings or errors in the debug output? These calls are the primary way to copy from one texture to another, so if they're not working I must be misunderstanding something about your original question. – Loyceloyd

Sorry about the misinformation. It didn't pass the texture over. But I just realize today that, actually it did, just that I need to dispose the texture then the 1st program will show the texture. So now i resolved to using CopyResource(). But have to recreate the texture on every reload. Could it be "lock" that's causing the texture not readable by the 1st program? – Aixlachapelle

Not sure what you mean by "lock". Shared surfaces are tricky: because rendering commands (including Copy*()) are queued by DX, you need to somehow make sure the queue is flushed and commands completed before reading from the shared surface. Disposing the texture probably does this implicitly. In C++ you'd use the IDXGIKeyedMutex interface to accomplish this without destroying and re-creating the source texture; I don't know whether this is available in SlimDX. – Loyceloyd