hi
B. Bogart wrote:
I'm still debugging my patch, but adding a whole lot of arbitrary delays (150ms) are being used to get PD to wait a little bit before accessing the image in a buffer once it has been written.
i agree to hans that this is the worst imaginable way to solve the problem (in theory)
Seems the safest way...
I remember Cyrille did mention needing to use these delays to make things work. I had to use them in parts of pixelTANGO also (when a message gets passed through many objects and many routes it takes time...)
as said before: it takes 0 logical time! (it takes real time of course)
As I have not noticed any render blocks with pix_buffer stuff, can I assume it uses a thread like pix_image and so on? I think a "done" bang would be really useful there.
iirc, my goal was rather to be in sync with the gemchain. so if you send an "open" message to [pix_image] you should be guaranteed, that in the next render cycle the image is loaded. the object might block this render cycle untill it has finished loading the image. i think this is better than adding another outlet.
I also had issues with things like pix_histo, where I would try and save the hist, but the hist had not changed for the new pix_buffer_read frame, just because the delay was slower than t b b delay.
afair, neither [pix_buffer*] nor [pix_histo] do _any_ threading. (threading is used very sparingly and only when system i/o is involved)
Are cyrille and I the only ones seeing these kinds of issues?
probably not. i just find it hard to believe without any proof :-)
fgmrad IOhannes