I would like to use the SharedMemory(Texture) to improve capture thread.
I used two instance of vvvv
I made a patch with a videoIn node connected to a videoOut(SharedMemory).
I made a patch with a SharedMemory(Texture) node > quad > renderer.
It works good until there are some vertical scratchs like bad vertical sync.
Is there a solution to kill these scratchs?
the tearing is by design, as the threads are not synced. one could think about a syncing mechanism, which would need some additional coding though…
note that the videoout (sharedmem) is opensource…so if you want to play around with that…of course the sharedmem(texture) would also need some tuning…
i am not sure though if it brings you the desired effect anyway.
I don’t khnow if I have the skill for this job but I would like to understand.
The first thread write in the memory at his rate.
The second thread read the same memory space at his rate.
Maybe the first thread should write in two differents memory space by alternating. The second thread could then read each time the filled memory space.
Is it a good approach according to you?
ja, something like that. the first thread must not read in location0 while thread 2 reads from there and viceversa. so there needs to be some mechanism that switches the memorylocations…
and what if you have more than one reading thread?
For the begining maybe the nodes could have a “lock enable” pin.
aaargh, I was thinking that putting all these nodes on a same patch could eliminate the tearing, but tearing appear sometimes.
ouright…>beta16 has a Use Sync pin on the SharedMemory (EX9.Texture) node.
with one reading SharedMemory (EX9.Texture) this should prevent tearing. if you have more reading textures you’ll have tearing again. i was also wondering if there could appear single frame drops since the two threads are not really synced but it’s only prevented that they access the memory at the same time…
please report back your findings. also, if your idea really brings the desired advantage.