MakeTexture speed

Hi all,

We're thinking of migrating some tests to PsychToolbox so they can run
in OS X natively, but we're running into some speed problems. They're
random dot motion tests, running on a 1.8Ghz G5, which should be
plenty fast. Anyway, the call in question is:

b(i) = Screen('MakeTexture', screenNum, img);

where imgR is a 765x765 pixel array on a 1280x1024 screen to get the
proper size, screenNum comes from Screen('screens').

The call takes on average 0.1s, meaning a 10-frame stimulus takes ~1s
to generate (just for the MakeTexture calls, generating the dots
themselves put this up closer to 2s, but that's not a psychtoolbox
issue). It's not really feasible to wait this long between stimulus
presentations when giving a test. By reducing the resolution to
800x640, the pixel array doesn't need to be quite as big, and we can
get the MakeTexture time down to ~0.07 per frame (so still >1s total
to generate a 10-frame stimulus).

(To clarify-- displaying the stimuli is fine, it's just in the
generation/maketexture process that these delays occur, meaning long
waits after a subject gives their response)

So, is there anything we can do to make this call faster? We've tried
using other window pointers than the fullscreen, but without much luck
(or knowing exactly what to try). Failing that, what is the limiting
factor on speed for the MakeTexture call? Anything that might improve
in the future?

We've timed the demos for similarly sized stimuli and get the same
problem. It's not as much of a problem for small stimuli or only a
few frames, but that's not usually possible for us, and even 10-frames
is often not enough.

Any suggestions?

Thanks very much!

Finnegan
We do the following to make things faster...

texts = zeros(1, frames, 'double');
for f = 1:frames,
texts(f) = Screen('MakeTexture', screenNumber, squeeze(img(f,:,:,:)));
end

for f = 1:frames,
Screen('DrawTexture', w, texts(f)); % display the movie frame
Screen('Flip', w);
end

--- In psychtoolbox@yahoogroups.com, "finn_calabro" <finn_calabro@y...> wrote:
>
>
> Hi all,
>
> We're thinking of migrating some tests to PsychToolbox so they can run
> in OS X natively, but we're running into some speed problems. They're
> random dot motion tests, running on a 1.8Ghz G5, which should be
> plenty fast. Anyway, the call in question is:
>
> b(i) = Screen('MakeTexture', screenNum, img);
>
> where imgR is a 765x765 pixel array on a 1280x1024 screen to get the
> proper size, screenNum comes from Screen('screens').
>
> The call takes on average 0.1s, meaning a 10-frame stimulus takes ~1s
> to generate (just for the MakeTexture calls, generating the dots
> themselves put this up closer to 2s, but that's not a psychtoolbox
> issue). It's not really feasible to wait this long between stimulus
> presentations when giving a test. By reducing the resolution to
> 800x640, the pixel array doesn't need to be quite as big, and we can
> get the MakeTexture time down to ~0.07 per frame (so still >1s total
> to generate a 10-frame stimulus).
>
> (To clarify-- displaying the stimuli is fine, it's just in the
> generation/maketexture process that these delays occur, meaning long
> waits after a subject gives their response)
>
> So, is there anything we can do to make this call faster? We've tried
> using other window pointers than the fullscreen, but without much luck
> (or knowing exactly what to try). Failing that, what is the limiting
> factor on speed for the MakeTexture call? Anything that might improve
> in the future?
>
> We've timed the demos for similarly sized stimuli and get the same
> problem. It's not as much of a problem for small stimuli or only a
> few frames, but that's not usually possible for us, and even 10-frames
> is often not enough.
>
> Any suggestions?
>
> Thanks very much!
>
> Finnegan
That's the same thing we've done, but the problem is the time it takes
to execute the Screen('MakeTexture') call. For a 10-frame stimulus,
where img(f,...) is reasonably large (>500x500) it takes close to 1
second. Adding in even a minimal amount of time to generate
img(f,...) means that pregenerating the stimulus can take 1.5-2
seconds. When we're presenting stimuli to subjects, it's not really
possible to have that much of a delay between presentations,
especially in a 2AFC task and the subject has to see two of them and
make a decision (if we pregenerate both of them, then we're waiting
3-4 seconds between stimuli).

So, I guess I'm wondering if there's a way to do the MakeTexture call
quicker.

Another solution would be if there was some way to copy directly
between textures very quickly, so we could copy each antialiased dot
from a texture template into the frame texture. Is there any way to
do something like this?

Thanks,
Finnegan



--- In psychtoolbox@yahoogroups.com, "Michael J. Tarr"
<michael_tarr@b...> wrote:
>
>
> We do the following to make things faster...
>
> texts = zeros(1, frames, 'double');
> for f = 1:frames,
> texts(f) = Screen('MakeTexture', screenNumber,
squeeze(img(f,:,:,:)));
> end
>
> for f = 1:frames,
> Screen('DrawTexture', w, texts(f)); % display the movie
frame
> Screen('Flip', w);
> end
>
> --- In psychtoolbox@yahoogroups.com, "finn_calabro"
<finn_calabro@y...> wrote:
> >
> >
> > Hi all,
> >
> > We're thinking of migrating some tests to PsychToolbox so they can run
> > in OS X natively, but we're running into some speed problems. They're
> > random dot motion tests, running on a 1.8Ghz G5, which should be
> > plenty fast. Anyway, the call in question is:
> >
> > b(i) = Screen('MakeTexture', screenNum, img);
> >
> > where imgR is a 765x765 pixel array on a 1280x1024 screen to get the
> > proper size, screenNum comes from Screen('screens').
> >
> > The call takes on average 0.1s, meaning a 10-frame stimulus takes ~1s
> > to generate (just for the MakeTexture calls, generating the dots
> > themselves put this up closer to 2s, but that's not a psychtoolbox
> > issue). It's not really feasible to wait this long between stimulus
> > presentations when giving a test. By reducing the resolution to
> > 800x640, the pixel array doesn't need to be quite as big, and we can
> > get the MakeTexture time down to ~0.07 per frame (so still >1s total
> > to generate a 10-frame stimulus).
> >
> > (To clarify-- displaying the stimuli is fine, it's just in the
> > generation/maketexture process that these delays occur, meaning long
> > waits after a subject gives their response)
> >
> > So, is there anything we can do to make this call faster? We've tried
> > using other window pointers than the fullscreen, but without much luck
> > (or knowing exactly what to try). Failing that, what is the limiting
> > factor on speed for the MakeTexture call? Anything that might improve
> > in the future?
> >
> > We've timed the demos for similarly sized stimuli and get the same
> > problem. It's not as much of a problem for small stimuli or only a
> > few frames, but that's not usually possible for us, and even 10-frames
> > is often not enough.
> >
> > Any suggestions?
> >
> > Thanks very much!
> >
> > Finnegan
Thanks to Finn Calabro's suggestion and code, I have modified the
Screen DrawDots subfunction to draw antialiased circular dots. This
option is enabled with a flag--see the help file in
Screen('DrawDots?'). The drawing is also now much faster. My (slow)
machine can draw about 20000 dots per frame.

Allen, is there any chance you can merge this DrawDots subfunction into
the main code? I've put the new source code on my web page mentioned
below. Thanks!

keith

On Dec 13, 2004, at 6:01 PM, Keith Schneider wrote:

>
> I just wrote a screen subfunction SCREEN('DrawDots'). This allows you
> to quickly draw an array of small dots to the screen. On my relatively
> slow machine I can draw over 7500 dots per 13.3 ms frame. Maybe you
> can use this instead of textures. Any feedback is appreciated.
>
> You can download the programs at www.princeton.edu/~kas/drawdots
>
> Here there is the compiled Screen.mexmac (replace yours in
> Psychtoolbox/PsychBasic), the source SCREENDrawDots.c and a demo
> dot_demo.m.
>
> If you want to incorporate this into your own source, you also need to
> add a line to Screen.h and RegisterProject.c. (I have not been able to
> locate the "How to Add Module Authors" document that Alan mentions in
> his How_To_Add_To_Screen.h file.)
>
> Maybe Alan can merge this into the normal Screen source at some point
> if people find this useful.
>
> keith
> Allen, is there any chance you can merge this DrawDots subfunction into
> the main code?

Dear Keith,

Sure. I'll either fold it into 1.0.4 or soon after.

I have just revised the roadmap numbering scheme to make space for
unscheduled releases between planned milestones.

The attached rtf file explains the change.

best,

Allen
Hi all,

The OS X Psychtoolbox 1.0.4 release will be postponed to tomorrow,
Saturday 18 December from today, Friday 17 December.

best,

Allen
Are you trying to do Bubbles or something?

On 8/15/07, Craig Aaen-Stockdale <craig.aaenstockdale@... > wrote:
Thanks for your replies. Ideally, I'd like the dots to be a modulation of background noise, but this doesn't seem to be possible with the DrawDots function. DrawTextures might be the way to go.

Craig Aaen-Stockdale
McGill Vision Research
Dept. of Ophthalmology, McGill University
687 Pine Avenue West, Rm. H4.14
Montreal, Quebec, Canada H3A 1A1
Tel : 514 843 1690




If you are just modulating the background, you could use the alpha channel of a uniform dot, which will be mathematically combined with the background, depending on the alphablending method you've specified. Not sure if this will do what you want, though.

keith

On Aug 15, 2007, at 9:06 AM, Craig Aaen-Stockdale wrote:

Thanks for your replies. Ideally, I'd like the dots to be a modulation of background noise, but this doesn't seem to be possible with the DrawDots function. DrawTextures might be the way to go.

Craig Aaen-Stockdale
McGill Vision Research
Dept. of Ophthalmology, McGill University
687 Pine Avenue West, Rm. H4.14
Montreal, Quebec, Canada H3A 1A1
Tel : 514 843 1690




Thanks for the sample code, Mario (and the background explanation!).
I'm on a G4 running Matlab 7.2.0 and Psychtoolbox 3.0.8 beta.

-Craig