Fwd: 800 Rectangles

1
Frans,

I decided to go with this version instead:

------------------------------
w=Screen('OpenWindow', screenNumber);

sizeX=20;
sizeY=10;

for j = 1:800
posx = rand * 1024;
posy = rand * 786;
color = rand * 255;
Screen('FillRect', w, [color color color] ,[ posx posy posx+sizeX
posy+sizeY]);
end

imgtest = Screen('GetImage', w, [], 'backBuffer');
imgtexture = Screen('MakeTexture', w, imgtest);

....
...
sometimes later:
Screen('DrawTexture', w, imgtexture);
Screen('Flip', w );
------------------------------

this is due to the fact that I do some complicated calculations which
I need to do before the experiment. There's not enough time to
calculate this between each trial. I know that GetImage is
comparatively slow but I don't see any alternative to this.


Andreas



On 1/20/07, Frans Cornelissen <f.w.cornelissen@...> wrote:
>
> Andreas,
>
> There is no real problem here, and for this you do not even need to invoke
> the use of textures.
> In the OpenGL toolbox, nothing appears on screen until you issue a screen
> flip command
>
> So your bit of code could look like:
>
> Screen('FillRect', window, gray);
> [h,v]=WindowSize(window); % to make this somewhat resolution independent
> % create a screen with 800 items on it
> for j = 1:800
> posx = round(rand * h);
> posy = round(rand * v);
> ...
> ...
> Screen('FillRect', window, colorTarget ,[ posx posy posx+sizeX
> posy+sizeY]);
> end
>
> Screen('Flip', window); % show rectangles on screen
>
> So, in fact it is simpler.
> Of course, the above assumes there is enough time to do this (i.e. you don't
> need to
> do a new screen every frame at very high refresh).
>
> You could also take a look at dotdemo.m in the PsychDemo folder, which shows
> a way of drawing many dots (of different sizes) using one Screen Drawdots
> command.
>
>
> Gr.
> Frans
>
>
>
>
>
>
> btw: about the whole think in textures problem. I really need to
> create my displays before the experiment. my display contains of maybe
> up to 800 rects so I rather compute everything before the experiment:
>
> BigScreens(i) = Screen(window,'OpenOffscreenWindow');
> Screen(BigScreens(i),'FillRect', gray);
>
> % create a screen with 800 items on it
> for j = 1:800
>
> posx = rand * 1024;
> posy = rand * 786;
> ...
> ...
> Screen(BigScreens(i),'FillRect', colorTarget ,[ posx
> posy
> posx+sizeX posy+sizeY]);
> end
>
2
Mario,


> If i run your code snippet (with DrawTexture or CopyWindow) i get
> exactly the expected result: A sky blue image.
>
> -> Bug in your system or a very old PTB.

none of both I would say. I have the latest PTB and I can't get this
running neither on linux nor on XP.

> Tested on NVidia GF7800, WinXP. Do you run the latest beta? What
> OS+Graphics card? Any special settings or warning output by PTB at
> startup?

ok, here's the deal: I don't run XP native but in VMWare. For me
that's been with the old PTB-2 a very nice way to design and test
experiments before I actually try them on my experimental pc. But
opengl seems to give it a hard time:

PTB-INFO: OpenGL-Renderer is Microsoft Corporation :: GDI Generic :: 1.1.0

on my linux box matlab just crashes if I don't use
Screen('Preference', 'SkipSyncTests', 2);
so currently I'm stuck and can't test / code anything except on my
experimental pc. can I expect any cure for this or ist microsoft
opengl not supported?

btw: is the eyelink toolbox supposed to work on linux? it doesn't seem
to do so here...

cheers,
andreas
3
Sorry, then its most likely a bug in Microsofts Software OpenGL
renderer. No surprise, i can't remember seeing this working correctly
anytime. When PTB spills dozens of warnings about the GDI its usually
the end of the road(TM). No hope here, developing on a well working
WinXP with proper native drivers from the vendors is already hell, i
won't spend a minute trying to fix anything related to the MS-OpenGL.

Eyelink is not supported on Linux, but i assume it would be trivial to
do so, basically just adapting the build-script. Unfortunately i don't
have the time now. The Linux PTB currently is mostly for special
applications and "do it yourself" users that now how to use a
compiler. Its very strong (= far superior) in a few areas where i need
it to be strong for my own work, but i don't have time to keep it
completely in sync with the other PTB's at the moment. It would be
good to know how many people are really interested in Linux PTB and
what their research areas are to get a feeling on how much time to
spend on it.

-mario

--- In psychtoolbox@yahoogroups.com, "Andreas Kotowicz" <kotowicz@...>
wrote:
>
> Mario,
>
>
> > If i run your code snippet (with DrawTexture or CopyWindow) i get
> > exactly the expected result: A sky blue image.
> >
> > -> Bug in your system or a very old PTB.
>
> none of both I would say. I have the latest PTB and I can't get this
> running neither on linux nor on XP.
>
> > Tested on NVidia GF7800, WinXP. Do you run the latest beta? What
> > OS+Graphics card? Any special settings or warning output by PTB at
> > startup?
>
> ok, here's the deal: I don't run XP native but in VMWare. For me
> that's been with the old PTB-2 a very nice way to design and test
> experiments before I actually try them on my experimental pc. But
> opengl seems to give it a hard time:
>
> PTB-INFO: OpenGL-Renderer is Microsoft Corporation :: GDI Generic ::
1.1.0
>
> on my linux box matlab just crashes if I don't use
> Screen('Preference', 'SkipSyncTests', 2);
> so currently I'm stuck and can't test / code anything except on my
> experimental pc. can I expect any cure for this or ist microsoft
> opengl not supported?
>
> btw: is the eyelink toolbox supposed to work on linux? it doesn't seem
> to do so here...
>
> cheers,
> andreas
>
4
On 1/21/07, Mario Kleiner <mario.kleiner@...> wrote:
> If you really think you need to cache the images then use Offscreen
> windows, i.e., use the Screen('OpenOffscreenWindow',...) command to
> create one, then draw your rects into it. Offscreen windows can be
> used anywhere you can use textures in PTB because internally they are
> (nearly) the same, e.g., you can pass a Offscreen window handle to
> Screen('DrawTexture') as if it is a texture.

I tried this and though it is faster than the previous method it still is slow.

> However even if you need to precompute parameters, you could store
> them in a matlab array and just draw them in a Screen('FillRect', ...)
> loop. That would be probably faster and more memory efficient.

So you mean I should compute them and later just loop through the
amount of items and place them directly onto the window?

why doesn't the following work:

img = imread([basepathImgs 'img.png']);
Screen('FillRect', window, backgroundcolor);
NewTexture = Screen('MakeTexture', window, img);

somehow the color I pass with backgroundcolor get's ignored. it only
get's picked up if I use e.g. [0 0 0] instead. that shouldn't happen
though, right? (and this is on a real XP machine now :)

andreas
5
On 1/24/07, Mario Kleiner <mario.kleiner@...> wrote:
> > Sorry, then its most likely a bug in Microsofts Software OpenGL
> renderer. No surprise, i can't remember seeing this working correctly
> anytime. When PTB spills dozens of warnings about the GDI its usually
> the end of the road(TM). No hope here, developing on a well working
> WinXP with proper native drivers from the vendors is already hell, i
> won't spend a minute trying to fix anything related to the MS-OpenGL.

fair enough :)

> Eyelink is not supported on Linux, but i assume it would be trivial to
> do so, basically just adapting the build-script. Unfortunately i don't
> have the time now. The Linux PTB currently is mostly for special
> applications and "do it yourself" users that now how to use a
> compiler. Its very strong (= far superior) in a few areas where i need
> it to be strong for my own work, but i don't have time to keep it
> completely in sync with the other PTB's at the moment. It would be
> good to know how many people are really interested in Linux PTB and
> what their research areas are to get a feeling on how much time to
> spend on it.

I would be interested. I do visual search so that's a reason why I'm
using the eyelink toolbox.
For me it would be good enough if the eyelink toolbox would just work
in dummy mode so I can actually just test stuff (without commenting it
out). because right now when ever I have a call like:
Eyelink('initializedummy') I always get:

??? Error using ==> Eyelink
Too many input arguments.

which could be easily avoided by just checking if the OS is linux, right?
I think I could try and get some time to play with those things.

cheers,
andreas
6
Hi Mario and Andreas,

>> It would be
>> good to know how many people are really interested in Linux PTB and
>> what their research areas are to get a feeling on how much time to
>> spend on it.
We would be very interested on a Linux PTB. We do mainly auditory
research, but the timing accuracy of the Windows based MATLAB built-in
as well as PTB sound functions is rather low. I hoped that it might be
very much easier implementing reasonable sound functionality under
Linux. Unfortunately, I did not yet find time to dig deeper.

> For me it would be good enough if the eyelink toolbox would just work
> in dummy mode so I can actually just test stuff (without commenting it
> out). because right now when ever I have a call like:
> Eyelink('initializedummy') I always get:
>
> ??? Error using ==> Eyelink
> Too many input arguments.
I sometimes use overloading in these situations, e.g.

function somefun
if isunix
Eyelink = @foobar;
end
Eyelink('initializedummy')

function foobar(str)
disp('Hello world')

Maybe this helps?

Best,
Andreas
7
--- In psychtoolbox@yahoogroups.com, "Andreas Kotowicz" <kotowicz@...>
wrote:
>
> On 1/21/07, Mario Kleiner <mario.kleiner@...> wrote:
> > If you really think you need to cache the images then use Offscreen
> > windows, i.e., use the Screen('OpenOffscreenWindow',...) command to
> > create one, then draw your rects into it. Offscreen windows can be
> > used anywhere you can use textures in PTB because internally they are
> > (nearly) the same, e.g., you can pass a Offscreen window handle to
> > Screen('DrawTexture') as if it is a texture.
>
> I tried this and though it is faster than the previous method it
still is slow.

Yes, the current implementation of Offscreen windows is written for
backward compatibility to old gfx-hw, not speed. Switching between
drawing into different windows is relatively slow. It also depends on
your gfx-hardware how slow "slow" is. It always helps to keep the
offscreen windows as small as possible, often stims don't extend over
the whole display area.

If you have recent hw with the latest gfx-drivers you could try to
enable fast Offscreen window support by setting the optional
'imagingmode' flag of Screen('OpenWindow',....,imagingmode) to
kPsychNeedFastBackingStore - this will either abort with some errors
about unsupported hardware or give you the fastest possible
implementation of offscreen drawing on todays graphics hardware. This
codepath is only a few days old however and only tested on a limited
number of machines.

>
> > However even if you need to precompute parameters, you could store
> > them in a matlab array and just draw them in a Screen('FillRect',
...)
> > loop. That would be probably faster and more memory efficient.
>
> So you mean I should compute them and later just loop through the
> amount of items and place them directly onto the window?

Yes! That would be the most elegant solution if its fast enough.

>
> why doesn't the following work:
>
> img = imread([basepathImgs 'img.png']);
> Screen('FillRect', window, backgroundcolor);
> NewTexture = Screen('MakeTexture', window, img);
>
> somehow the color I pass with backgroundcolor get's ignored. it only
> get's picked up if I use e.g. [0 0 0] instead. that shouldn't happen
> though, right? (and this is on a real XP machine now :)
>

I don't know, it works perfectly on all of my setups :) - you must do
something wrong with your backgroundcolor variable?

-mario
8
On 2/11/07, Mario Kleiner <mario.kleiner@...> wrote:

> No. Its as fast as it gets with the current PTB implementation. What you measure is
> mostly PTB's overhead.

very strange. If I do run the same timing code but draw the stimuls to
an offscreenwindow and issue the CopyWindow command (and setting the
imagingmode to kPsychNeedFastBackingStore), the time is actually at
around 1ms. So where did the overhead go in this case?

andreas
9
On 2/11/07, Mario Kleiner <mario.kleiner@...> wrote:

> No. Its as fast as it gets with the current PTB implementation. What you measure is mostly
> PTB's overhead.

what is then the correct way of measuring the drawing time instead of
PTB's overhead? something like this:

[VBLTimestamp StimulusOnsetTime FlipTimestamp Missed Beampos] =
Screen('Flip', win);
drawtime = FlipTimestamp - VBLTimestamp;


andreas
10
Hi Mario,

Is the code you created to batch draw rects with FillRect in the
repository? And can I use it under windows?

I tried an UpdatePscyhtoolbox, looked at the help for FillRect, and it
doesn't indicate it can take a vector.
I'm running PsychtooboxVersion
3.0.8 - Flavor: beta - Corresponds to SVN Revision 703

I'm trying to create a Mondrian pattern 'movie', and this
functionality will greatly help with that.

Thank you for any help in advance.

Best regards,

-Sam

--- In psychtoolbox@yahoogroups.com, "Mario Kleiner"
<mario.kleiner@...> wrote:
>
> hi again,
>
> the "perfect" way is to do:
> telapsed = Screen('DrawingFinished', window, 0, 1);
>
> telapsed will be the elapsed time between the last 'Flip'
> command and completion of all drawing commands
> before the 'DrawingFinished' command. This command
> itself induces overhead, so don't use it with the sync-
> flag set to 1 in finished exp. code, its only for timing the
> gfx-engine.
>
> But your numbers with your method are mostly correct,
> the 'FillRect' call takes "long" to execute. Its not Matlab or
> the actual drawing that takes much time, its the setup code
> inside PTB. I've implemented batch drawing (like in DrawDots
> and DrawLines) for the 'FillRect' command. This is much
> faster because the costs for setup are paid only once for
> the whole batch of rects, about 1 microsecond per rect on
> a MacBookPro, compared to 50 microseconds old style.
>
> New code will be part of next beta update this evening, didn't
> get around to make the remaining commands batch-aware.
>
> best,
> -mario
>
> --- In psychtoolbox@yahoogroups.com, "Andreas Kotowicz" <kotowicz@>
wrote:
> >
> > On 2/11/07, Mario Kleiner <mario.kleiner@> wrote:
> >
> > > No. Its as fast as it gets with the current PTB implementation.
What you measure is
> mostly
> > > PTB's overhead.
> >
> > what is then the correct way of measuring the drawing time instead of
> > PTB's overhead? something like this:
> >
> > [VBLTimestamp StimulusOnsetTime FlipTimestamp Missed Beampos] =
> > Screen('Flip', win);
> > drawtime = FlipTimestamp - VBLTimestamp;
> >
> >
> > andreas
> >
>
11
It is in the beta afaik, but i forgot to update the online-help for it.

Simply pass matrices in place of the single arguments, e.g.,

instead of the rect parameter, pass a 4 x n matrix where rows 1-4 encode the [left top
right bottom] corners of a rect, the i'th column encodes the i'th rect. For the color
argument you can pass a corresponding matrix.

best,
-mario

--- In psychtoolbox@yahoogroups.com, "Samuel Inverso" <sam.inverso@...> wrote:
>
> Hi Mario,
>
> Is the code you created to batch draw rects with FillRect in the
> repository? And can I use it under windows?
>
> I tried an UpdatePscyhtoolbox, looked at the help for FillRect, and it
> doesn't indicate it can take a vector.
> I'm running PsychtooboxVersion
> 3.0.8 - Flavor: beta - Corresponds to SVN Revision 703
>
> I'm trying to create a Mondrian pattern 'movie', and this
> functionality will greatly help with that.
>
> Thank you for any help in advance.
>
> Best regards,
>
> -Sam
>
> --- In psychtoolbox@yahoogroups.com, "Mario Kleiner"
> <mario.kleiner@> wrote:
> >
> > hi again,
> >
> > the "perfect" way is to do:
> > telapsed = Screen('DrawingFinished', window, 0, 1);
> >
> > telapsed will be the elapsed time between the last 'Flip'
> > command and completion of all drawing commands
> > before the 'DrawingFinished' command. This command
> > itself induces overhead, so don't use it with the sync-
> > flag set to 1 in finished exp. code, its only for timing the
> > gfx-engine.
> >
> > But your numbers with your method are mostly correct,
> > the 'FillRect' call takes "long" to execute. Its not Matlab or
> > the actual drawing that takes much time, its the setup code
> > inside PTB. I've implemented batch drawing (like in DrawDots
> > and DrawLines) for the 'FillRect' command. This is much
> > faster because the costs for setup are paid only once for
> > the whole batch of rects, about 1 microsecond per rect on
> > a MacBookPro, compared to 50 microseconds old style.
> >
> > New code will be part of next beta update this evening, didn't
> > get around to make the remaining commands batch-aware.
> >
> > best,
> > -mario
> >
> > --- In psychtoolbox@yahoogroups.com, "Andreas Kotowicz" <kotowicz@>
> wrote:
> > >
> > > On 2/11/07, Mario Kleiner <mario.kleiner@> wrote:
> > >
> > > > No. Its as fast as it gets with the current PTB implementation.
> What you measure is
> > mostly
> > > > PTB's overhead.
> > >
> > > what is then the correct way of measuring the drawing time instead of
> > > PTB's overhead? something like this:
> > >
> > > [VBLTimestamp StimulusOnsetTime FlipTimestamp Missed Beampos] =
> > > Screen('Flip', win);
> > > drawtime = FlipTimestamp - VBLTimestamp;
> > >
> > >
> > > andreas
> > >
> >
>
12
It is in the beta afaik, but i forgot to update the online-help for it.

Simply pass matrices in place of the single arguments, e.g.,

instead of the rect parameter, pass a 4 x n matrix where rows 1-4 encode the [left top
right bottom] corners of a rect, the i'th column encodes the i'th rect. For the color
argument you can pass a corresponding matrix.

best,
-mario

--- In psychtoolbox@yahoogroups.com, "Samuel Inverso" <sam.inverso@...> wrote:
>
> Hi Mario,
>
> Is the code you created to batch draw rects with FillRect in the
> repository? And can I use it under windows?
>
> I tried an UpdatePscyhtoolbox, looked at the help for FillRect, and it
> doesn't indicate it can take a vector.
> I'm running PsychtooboxVersion
> 3.0.8 - Flavor: beta - Corresponds to SVN Revision 703
>
> I'm trying to create a Mondrian pattern 'movie', and this
> functionality will greatly help with that.
>
> Thank you for any help in advance.
>
> Best regards,
>
> -Sam
>
> --- In psychtoolbox@yahoogroups.com, "Mario Kleiner"
> <mario.kleiner@> wrote:
> >
> > hi again,
> >
> > the "perfect" way is to do:
> > telapsed = Screen('DrawingFinished', window, 0, 1);
> >
> > telapsed will be the elapsed time between the last 'Flip'
> > command and completion of all drawing commands
> > before the 'DrawingFinished' command. This command
> > itself induces overhead, so don't use it with the sync-
> > flag set to 1 in finished exp. code, its only for timing the
> > gfx-engine.
> >
> > But your numbers with your method are mostly correct,
> > the 'FillRect' call takes "long" to execute. Its not Matlab or
> > the actual drawing that takes much time, its the setup code
> > inside PTB. I've implemented batch drawing (like in DrawDots
> > and DrawLines) for the 'FillRect' command. This is much
> > faster because the costs for setup are paid only once for
> > the whole batch of rects, about 1 microsecond per rect on
> > a MacBookPro, compared to 50 microseconds old style.
> >
> > New code will be part of next beta update this evening, didn't
> > get around to make the remaining commands batch-aware.
> >
> > best,
> > -mario
> >
> > --- In psychtoolbox@yahoogroups.com, "Andreas Kotowicz" <kotowicz@>
> wrote:
> > >
> > > On 2/11/07, Mario Kleiner <mario.kleiner@> wrote:
> > >
> > > > No. Its as fast as it gets with the current PTB implementation.
> What you measure is
> > mostly
> > > > PTB's overhead.
> > >
> > > what is then the correct way of measuring the drawing time instead of
> > > PTB's overhead? something like this:
> > >
> > > [VBLTimestamp StimulusOnsetTime FlipTimestamp Missed Beampos] =
> > > Screen('Flip', win);
> > > drawtime = FlipTimestamp - VBLTimestamp;
> > >
> > >
> > > andreas
> > >
> >
>
13
It is in the beta afaik, but i forgot to update the online-help for it.

Simply pass matrices in place of the single arguments, e.g.,

instead of the rect parameter, pass a 4 x n matrix where rows 1-4 encode the [left top
right bottom] corners of a rect, the i'th column encodes the i'th rect. For the color
argument you can pass a corresponding matrix.

best,
-mario

--- In psychtoolbox@yahoogroups.com, "Samuel Inverso" <sam.inverso@...> wrote:
>
> Hi Mario,
>
> Is the code you created to batch draw rects with FillRect in the
> repository? And can I use it under windows?
>
> I tried an UpdatePscyhtoolbox, looked at the help for FillRect, and it
> doesn't indicate it can take a vector.
> I'm running PsychtooboxVersion
> 3.0.8 - Flavor: beta - Corresponds to SVN Revision 703
>
> I'm trying to create a Mondrian pattern 'movie', and this
> functionality will greatly help with that.
>
> Thank you for any help in advance.
>
> Best regards,
>
> -Sam
>
> --- In psychtoolbox@yahoogroups.com, "Mario Kleiner"
> <mario.kleiner@> wrote:
> >
> > hi again,
> >
> > the "perfect" way is to do:
> > telapsed = Screen('DrawingFinished', window, 0, 1);
> >
> > telapsed will be the elapsed time between the last 'Flip'
> > command and completion of all drawing commands
> > before the 'DrawingFinished' command. This command
> > itself induces overhead, so don't use it with the sync-
> > flag set to 1 in finished exp. code, its only for timing the
> > gfx-engine.
> >
> > But your numbers with your method are mostly correct,
> > the 'FillRect' call takes "long" to execute. Its not Matlab or
> > the actual drawing that takes much time, its the setup code
> > inside PTB. I've implemented batch drawing (like in DrawDots
> > and DrawLines) for the 'FillRect' command. This is much
> > faster because the costs for setup are paid only once for
> > the whole batch of rects, about 1 microsecond per rect on
> > a MacBookPro, compared to 50 microseconds old style.
> >
> > New code will be part of next beta update this evening, didn't
> > get around to make the remaining commands batch-aware.
> >
> > best,
> > -mario
> >
> > --- In psychtoolbox@yahoogroups.com, "Andreas Kotowicz" <kotowicz@>
> wrote:
> > >
> > > On 2/11/07, Mario Kleiner <mario.kleiner@> wrote:
> > >
> > > > No. Its as fast as it gets with the current PTB implementation.
> What you measure is
> > mostly
> > > > PTB's overhead.
> > >
> > > what is then the correct way of measuring the drawing time instead of
> > > PTB's overhead? something like this:
> > >
> > > [VBLTimestamp StimulusOnsetTime FlipTimestamp Missed Beampos] =
> > > Screen('Flip', win);
> > > drawtime = FlipTimestamp - VBLTimestamp;
> > >
> > >
> > > andreas
> > >
> >
>
14
It is in the beta afaik, but i forgot to update the online-help for it.

Simply pass matrices in place of the single arguments, e.g.,

instead of the rect parameter, pass a 4 x n matrix where rows 1-4 encode the [left top
right bottom] corners of a rect, the i'th column encodes the i'th rect. For the color
argument you can pass a corresponding matrix.

best,
-mario

--- In psychtoolbox@yahoogroups.com, "Samuel Inverso" <sam.inverso@...> wrote:
>
> Hi Mario,
>
> Is the code you created to batch draw rects with FillRect in the
> repository? And can I use it under windows?
>
> I tried an UpdatePscyhtoolbox, looked at the help for FillRect, and it
> doesn't indicate it can take a vector.
> I'm running PsychtooboxVersion
> 3.0.8 - Flavor: beta - Corresponds to SVN Revision 703
>
> I'm trying to create a Mondrian pattern 'movie', and this
> functionality will greatly help with that.
>
> Thank you for any help in advance.
>
> Best regards,
>
> -Sam
>
> --- In psychtoolbox@yahoogroups.com, "Mario Kleiner"
> <mario.kleiner@> wrote:
> >
> > hi again,
> >
> > the "perfect" way is to do:
> > telapsed = Screen('DrawingFinished', window, 0, 1);
> >
> > telapsed will be the elapsed time between the last 'Flip'
> > command and completion of all drawing commands
> > before the 'DrawingFinished' command. This command
> > itself induces overhead, so don't use it with the sync-
> > flag set to 1 in finished exp. code, its only for timing the
> > gfx-engine.
> >
> > But your numbers with your method are mostly correct,
> > the 'FillRect' call takes "long" to execute. Its not Matlab or
> > the actual drawing that takes much time, its the setup code
> > inside PTB. I've implemented batch drawing (like in DrawDots
> > and DrawLines) for the 'FillRect' command. This is much
> > faster because the costs for setup are paid only once for
> > the whole batch of rects, about 1 microsecond per rect on
> > a MacBookPro, compared to 50 microseconds old style.
> >
> > New code will be part of next beta update this evening, didn't
> > get around to make the remaining commands batch-aware.
> >
> > best,
> > -mario
> >
> > --- In psychtoolbox@yahoogroups.com, "Andreas Kotowicz" <kotowicz@>
> wrote:
> > >
> > > On 2/11/07, Mario Kleiner <mario.kleiner@> wrote:
> > >
> > > > No. Its as fast as it gets with the current PTB implementation.
> What you measure is
> > mostly
> > > > PTB's overhead.
> > >
> > > what is then the correct way of measuring the drawing time instead of
> > > PTB's overhead? something like this:
> > >
> > > [VBLTimestamp StimulusOnsetTime FlipTimestamp Missed Beampos] =
> > > Screen('Flip', win);
> > > drawtime = FlipTimestamp - VBLTimestamp;
> > >
> > >
> > > andreas
> > >
> >
>
15
Hi Mario,

Great!
I had tried a n x 4 matrix, which is why it didn't work.
Also,
the colors have to be 3 x n or 4xn, it doesn't support single color
values ( 1 x n) as the original function did.

Now it works and is 10 times faster than a for loop! (averaged over
100 presentations of 420 rectangles of different colors 0.00024 vs
0.0026 seconds).

Best regards,

-Sam


--- In psychtoolbox@yahoogroups.com, "Mario Kleiner"
<mario.kleiner@...> wrote:
>
> It is in the beta afaik, but i forgot to update the online-help for it.
>
> Simply pass matrices in place of the single arguments, e.g.,
>
> instead of the rect parameter, pass a 4 x n matrix where rows 1-4
encode the [left top
> right bottom] corners of a rect, the i'th column encodes the i'th
rect. For the color
> argument you can pass a corresponding matrix.
>
> best,
> -mario
>
> --- In psychtoolbox@yahoogroups.com, "Samuel Inverso" <sam.inverso@>
wrote:
> >
> > Hi Mario,
> >
> > Is the code you created to batch draw rects with FillRect in the
> > repository? And can I use it under windows?
> >
> > I tried an UpdatePscyhtoolbox, looked at the help for FillRect, and it
> > doesn't indicate it can take a vector.
> > I'm running PsychtooboxVersion
> > 3.0.8 - Flavor: beta - Corresponds to SVN Revision 703
> >
> > I'm trying to create a Mondrian pattern 'movie', and this
> > functionality will greatly help with that.
> >
> > Thank you for any help in advance.
> >
> > Best regards,
> >
> > -Sam
> >
> > --- In psychtoolbox@yahoogroups.com, "Mario Kleiner"
> > <mario.kleiner@> wrote:
> > >
> > > hi again,
> > >
> > > the "perfect" way is to do:
> > > telapsed = Screen('DrawingFinished', window, 0, 1);
> > >
> > > telapsed will be the elapsed time between the last 'Flip'
> > > command and completion of all drawing commands
> > > before the 'DrawingFinished' command. This command
> > > itself induces overhead, so don't use it with the sync-
> > > flag set to 1 in finished exp. code, its only for timing the
> > > gfx-engine.
> > >
> > > But your numbers with your method are mostly correct,
> > > the 'FillRect' call takes "long" to execute. Its not Matlab or
> > > the actual drawing that takes much time, its the setup code
> > > inside PTB. I've implemented batch drawing (like in DrawDots
> > > and DrawLines) for the 'FillRect' command. This is much
> > > faster because the costs for setup are paid only once for
> > > the whole batch of rects, about 1 microsecond per rect on
> > > a MacBookPro, compared to 50 microseconds old style.
> > >
> > > New code will be part of next beta update this evening, didn't
> > > get around to make the remaining commands batch-aware.
> > >
> > > best,
> > > -mario
> > >
> > > --- In psychtoolbox@yahoogroups.com, "Andreas Kotowicz" <kotowicz@>
> > wrote:
> > > >
> > > > On 2/11/07, Mario Kleiner <mario.kleiner@> wrote:
> > > >
> > > > > No. Its as fast as it gets with the current PTB implementation.
> > What you measure is
> > > mostly
> > > > > PTB's overhead.
> > > >
> > > > what is then the correct way of measuring the drawing time
instead of
> > > > PTB's overhead? something like this:
> > > >
> > > > [VBLTimestamp StimulusOnsetTime FlipTimestamp Missed Beampos] =
> > > > Screen('Flip', win);
> > > > drawtime = FlipTimestamp - VBLTimestamp;
> > > >
> > > >
> > > > andreas
> > > >
> > >
> >
>
16
It is in the beta afaik, but i forgot to update the online-help for it.

Simply pass matrices in place of the single arguments, e.g.,

instead of the rect parameter, pass a 4 x n matrix where rows 1-4 encode the [left top
right bottom] corners of a rect, the i'th column encodes the i'th rect. For the color
argument you can pass a corresponding matrix.

best,
-mario

--- In psychtoolbox@yahoogroups.com, "Samuel Inverso" <sam.inverso@...> wrote:
>
> Hi Mario,
>
> Is the code you created to batch draw rects with FillRect in the
> repository? And can I use it under windows?
>
> I tried an UpdatePscyhtoolbox, looked at the help for FillRect, and it
> doesn't indicate it can take a vector.
> I'm running PsychtooboxVersion
> 3.0.8 - Flavor: beta - Corresponds to SVN Revision 703
>
> I'm trying to create a Mondrian pattern 'movie', and this
> functionality will greatly help with that.
>
> Thank you for any help in advance.
>
> Best regards,
>
> -Sam
>
> --- In psychtoolbox@yahoogroups.com, "Mario Kleiner"
> <mario.kleiner@> wrote:
> >
> > hi again,
> >
> > the "perfect" way is to do:
> > telapsed = Screen('DrawingFinished', window, 0, 1);
> >
> > telapsed will be the elapsed time between the last 'Flip'
> > command and completion of all drawing commands
> > before the 'DrawingFinished' command. This command
> > itself induces overhead, so don't use it with the sync-
> > flag set to 1 in finished exp. code, its only for timing the
> > gfx-engine.
> >
> > But your numbers with your method are mostly correct,
> > the 'FillRect' call takes "long" to execute. Its not Matlab or
> > the actual drawing that takes much time, its the setup code
> > inside PTB. I've implemented batch drawing (like in DrawDots
> > and DrawLines) for the 'FillRect' command. This is much
> > faster because the costs for setup are paid only once for
> > the whole batch of rects, about 1 microsecond per rect on
> > a MacBookPro, compared to 50 microseconds old style.
> >
> > New code will be part of next beta update this evening, didn't
> > get around to make the remaining commands batch-aware.
> >
> > best,
> > -mario
> >
> > --- In psychtoolbox@yahoogroups.com, "Andreas Kotowicz" <kotowicz@>
> wrote:
> > >
> > > On 2/11/07, Mario Kleiner <mario.kleiner@> wrote:
> > >
> > > > No. Its as fast as it gets with the current PTB implementation.
> What you measure is
> > mostly
> > > > PTB's overhead.
> > >
> > > what is then the correct way of measuring the drawing time instead of
> > > PTB's overhead? something like this:
> > >
> > > [VBLTimestamp StimulusOnsetTime FlipTimestamp Missed Beampos] =
> > > Screen('Flip', win);
> > > drawtime = FlipTimestamp - VBLTimestamp;
> > >
> > >
> > > andreas
> > >
> >
>
17
Hi Mario,

Great!
I had tried a n x 4 matrix, which is why it didn't work.
Also,
the colors have to be 3 x n or 4xn, it doesn't support single color
values ( 1 x n) as the original function did.

Now it works and is 10 times faster than a for loop! (averaged over
100 presentations of 420 rectangles of different colors 0.00024 vs
0.0026 seconds).

Best regards,

-Sam


--- In psychtoolbox@yahoogroups.com, "Mario Kleiner"
<mario.kleiner@...> wrote:
>
> It is in the beta afaik, but i forgot to update the online-help for it.
>
> Simply pass matrices in place of the single arguments, e.g.,
>
> instead of the rect parameter, pass a 4 x n matrix where rows 1-4
encode the [left top
> right bottom] corners of a rect, the i'th column encodes the i'th
rect. For the color
> argument you can pass a corresponding matrix.
>
> best,
> -mario
>
> --- In psychtoolbox@yahoogroups.com, "Samuel Inverso" <sam.inverso@>
wrote:
> >
> > Hi Mario,
> >
> > Is the code you created to batch draw rects with FillRect in the
> > repository? And can I use it under windows?
> >
> > I tried an UpdatePscyhtoolbox, looked at the help for FillRect, and it
> > doesn't indicate it can take a vector.
> > I'm running PsychtooboxVersion
> > 3.0.8 - Flavor: beta - Corresponds to SVN Revision 703
> >
> > I'm trying to create a Mondrian pattern 'movie', and this
> > functionality will greatly help with that.
> >
> > Thank you for any help in advance.
> >
> > Best regards,
> >
> > -Sam
> >
> > --- In psychtoolbox@yahoogroups.com, "Mario Kleiner"
> > <mario.kleiner@> wrote:
> > >
> > > hi again,
> > >
> > > the "perfect" way is to do:
> > > telapsed = Screen('DrawingFinished', window, 0, 1);
> > >
> > > telapsed will be the elapsed time between the last 'Flip'
> > > command and completion of all drawing commands
> > > before the 'DrawingFinished' command. This command
> > > itself induces overhead, so don't use it with the sync-
> > > flag set to 1 in finished exp. code, its only for timing the
> > > gfx-engine.
> > >
> > > But your numbers with your method are mostly correct,
> > > the 'FillRect' call takes "long" to execute. Its not Matlab or
> > > the actual drawing that takes much time, its the setup code
> > > inside PTB. I've implemented batch drawing (like in DrawDots
> > > and DrawLines) for the 'FillRect' command. This is much
> > > faster because the costs for setup are paid only once for
> > > the whole batch of rects, about 1 microsecond per rect on
> > > a MacBookPro, compared to 50 microseconds old style.
> > >
> > > New code will be part of next beta update this evening, didn't
> > > get around to make the remaining commands batch-aware.
> > >
> > > best,
> > > -mario
> > >
> > > --- In psychtoolbox@yahoogroups.com, "Andreas Kotowicz" <kotowicz@>
> > wrote:
> > > >
> > > > On 2/11/07, Mario Kleiner <mario.kleiner@> wrote:
> > > >
> > > > > No. Its as fast as it gets with the current PTB implementation.
> > What you measure is
> > > mostly
> > > > > PTB's overhead.
> > > >
> > > > what is then the correct way of measuring the drawing time
instead of
> > > > PTB's overhead? something like this:
> > > >
> > > > [VBLTimestamp StimulusOnsetTime FlipTimestamp Missed Beampos] =
> > > > Screen('Flip', win);
> > > > drawtime = FlipTimestamp - VBLTimestamp;
> > > >
> > > >
> > > > andreas
> > > >
> > >
> >
>