Hello,
im using beta28 which is a really great release. I`m playing around with the shared texture thing and it works really well.
But I have one little problem.
In Patch one (1th VVVV instance):
some stuff->to prerender in one Renderer->then I take this texture->
to the Final Renderer
In Patch two (2th VVVV instance):
I receive the texture from the Final Renderer(Patch1) with the shared texture node. Everything is fine, except fast animations which take place in the prerenderer of patch1 they are jaggy.
It seems like a timing issue between the renderers. I tried diffrent renderintervals but that didn`t help.
As a workaround I can simply get the two renderers with two shared textures, that works well. But I`m just wondering if there is a better way.
I have the same sort of issue, seems to happen if I’m sending a 128x128 texture or a 1024x1024 texture. Very fast content has some jitter, slower content is fine. Setting the instances to different CPU affinities also didn’t solve it.
The API that you use to open a shared resource must match the API that you used to create the shared resource. For example, if you used CreateTexture to create a shared resource, you must use CreateTexture to open that shared resource; if you used CreateRenderTarget to create a shared resource, you must use CreateRenderTarget to open that shared resource;and so on.
When you open a shared resource, you must specify D3DPOOL_DEFAULT.
Lockable resources (textures with D3DUSAGE_DYNAMIC, vertex buffers and index buffers, for instance) can experience poor performance when shared. Lockable rendertargets will fail to be shared on some hardware.
References to a cross-process shared resource must have the same dimensions as the original resource. When passing a handle across process, include the dimension information so that the reference can be created identically.
Shared cross-process surfaces provide no synchronization mechanism. Read/write changes to a shared surface may not reflect a referencing process’s view of the surface when expected. To provide synchronization, use event queries or lock the texture.
Only the process that initially creates a shared resource can lock it (any process that opens a reference to that shared resource cannot lock it).
If a shared resource is locked, there is no validation for other processes to know if the resource is available.
At this time, I don’t fully understand what all of the consequences are. And when I read the last 3 lines, it’s unclear to me whether locking the texture solves the problem. I mean:
will the drawing on the ‘receiving’ instance just block until the texture is unlocked, or something else?
And how does vvvv’s DX9Texture behave? Does it lock the texture before rendering, or not?
What are event queries, and how could they be used to provide synchronization?
Hey maybe I missused the word jaggy:-). It simply jitters,it looks like some frames of the prerenderer get skipped. I will test a few settings but right now I`m out of office for the next 2 days.
i don’t get that. in the workaround you’re talking of 2 textures. in the problem-description it sounds like you need to pipe one texture from A to B?!
what i noticed and cannot explain: when the Renderer (that has the DX9Texture connected) in A is hidden i get jitter. when it shows (even behind the fullscreen of a renderer in B it runs smoothly (tested with 3840x1080 texture).
Sorry for the late answer but i was on holiday :-)
The thing with the 2 textures,in patch one i have the prerenderer and the final renderer, in the final renderer the prerendered image gets rendered. And everything gets received in the 2. patch.
Now i send the prerenderer directly via shared texture and the final renderer without the prerendered image to another shared texture and compose the two textures in the receiver patch.
Thats works good
