I am trying to display random dot kinematograms with a large number of dots (around 100,000). I’m using ElementArrayStim for that, and usually the display duration is half a second to a second, or let’s say at max around 100 frames.
Right now I’m precomputing arrays with all dot positions, sizes, opacities, etc that contain all data for one trial (for positions the shape would be (100x100,000x2). Then, in the display loop I insert the current slice of preallocated values into the ElementArrayStim, which seems to be to slow not to drop frames sometimes at this dot number.
Can I tweak ElementArrayStim so it is faster? I noticed that the same configuration of dots is drawn super fast every time after the first, so I guess a texture with all the dots drawn on it is cached. But I don’t see how this could benefit me, as no dot configuration is ever drawn twice.
Thanks for your input, and let me know if I need to clarify something.
Julius
Hi, an interesting problem. Premature optimisation is the root of all evil, however. We can’t tell without seeing the code where any issues might lie, and even then, the definitive evidence would come from running a code profiler to identify where the actual bottleneck lies.
Having said that, if the issue is the generation of the texture from your data, then possible solutions could be:
Experiment with better hardware (CPU + GPU).
Go further with the caching: pre-generate bitmaps for each frame rather than just data. Presenting them in series should eliminate performance problems, but caching 100+ bitmaps per trial might or might not stress your video card memory.
Pre-generating all the bitmaps is probably best done before the experiment, then I guess per trial you would read in just the 100 or so needed for that trial: that would definitely take some time, which might or might not be feasible given the structure of experimental procedure (i.e. whether you have a sufficient inter-trial interval to work with).