I didn't know that, but it makes a lot of sense. I figured as long as you didn't touch the same pixel at the same time it'd be fine, but there would be no way to guarantee that.Daniel_Cortez wrote:Do you mean manipulating an image data in multiple threads or just moving all the manipulation code to another thread?T-Bone wrote:When you tried working with ImageData, did you use another thread? I don't think there's much point to it unless you use more than one thread. Optimally you should use as many threads as there are CPU cores.
Because using multiple threads will only make sense if you're going to manipulate 2 or more images in separate threads since setPixel and mapPixel methods are using mutexes.
The discussion here hasn't touched upon shaders much at all. They could probably be used; the actual rendering would certainly be very fast. But how should the data be sent to the shaders so that you actually win something in performance? Optimally, you would want to send minimal data (like less than the 2D array, more like some data from which the 2D array can be calculated) and do as much as possible in the shader... But that kind of depends on what kind of calculations you need. If the pixels are very correlated (the values of a pixel in position x depends on the pixels in x+1 and x-1 for example) then shaders won't help much since all the computations are "per-pixel".