# Fwd: 800 Rectangles **URL:** \ **Category:** Uncategorized\ **Created:** [January 20, 2007, 8:31pm UTC](https://psychtoolbox.discourse.group/t/fwd-800-rectangles/1221 "2007-01-20T20:31:50Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![Allen\_Ingling](https://avatars.discourse-cdn.com/v4/letter/a/a183cd/32.png) [@Allen\_Ingling](https://psychtoolbox.discourse.group/u/Allen_Ingling)\ **Post date:** [January 20, 2007, 8:31pm UTC](https://psychtoolbox.discourse.group/t/fwd-800-rectangles/1221/1 "2007-01-20T20:31:50Z")
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@...](mailto: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 > \> ---
**Author:** ![Allen\_Ingling](https://avatars.discourse-cdn.com/v4/letter/a/a183cd/32.png) [@Allen\_Ingling](https://psychtoolbox.discourse.group/u/Allen_Ingling)\ **Post date:** [January 24, 2007, 6:30am UTC](https://psychtoolbox.discourse.group/t/fwd-800-rectangles/1221/2 "2007-01-24T06:30:14Z")
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 ---
**Author:** ![mariokleiner](https://avatars.discourse-cdn.com/v4/letter/m/13edae/32.png) [@mariokleiner](https://psychtoolbox.discourse.group/u/mariokleiner)\ **Post date:** [January 24, 2007, 3:09pm UTC](https://psychtoolbox.discourse.group/t/fwd-800-rectangles/1221/3 "2007-01-24T15:09:41Z")
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](mailto:psychtoolbox@yahoogroups.com), "Andreas 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 > \> ---
**Author:** ![Allen\_Ingling](https://avatars.discourse-cdn.com/v4/letter/a/a183cd/32.png) [@Allen\_Ingling](https://psychtoolbox.discourse.group/u/Allen_Ingling)\ **Post date:** [January 25, 2007, 3:55am UTC](https://psychtoolbox.discourse.group/t/fwd-800-rectangles/1221/4 "2007-01-25T03:55:54Z")
On 1/21/07, Mario Kleiner \<[mario.kleiner@...](mailto: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 ---
**Author:** ![Allen\_Ingling](https://avatars.discourse-cdn.com/v4/letter/a/a183cd/32.png) [@Allen\_Ingling](https://psychtoolbox.discourse.group/u/Allen_Ingling)\ **Post date:** [January 25, 2007, 3:50am UTC](https://psychtoolbox.discourse.group/t/fwd-800-rectangles/1221/5 "2007-01-25T03:50:08Z")
On 1/24/07, Mario Kleiner \<[mario.kleiner@...](mailto: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 ---
**Author:** ![andreaswidmann](https://avatars.discourse-cdn.com/v4/letter/a/77aa72/32.png) [@andreaswidmann](https://psychtoolbox.discourse.group/u/andreaswidmann)\ **Post date:** [January 25, 2007, 10:09am UTC](https://psychtoolbox.discourse.group/t/fwd-800-rectangles/1221/6 "2007-01-25T10:09:31Z")
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 ---
**Author:** ![mariokleiner](https://avatars.discourse-cdn.com/v4/letter/m/13edae/32.png) [@mariokleiner](https://psychtoolbox.discourse.group/u/mariokleiner)\ **Post date:** [January 25, 2007, 2:47pm UTC](https://psychtoolbox.discourse.group/t/fwd-800-rectangles/1221/7 "2007-01-25T14:47:45Z")
--- In [psychtoolbox@yahoogroups.com](mailto:psychtoolbox@yahoogroups.com), "Andreas Kotowicz" \ wrote: > \> > \> On 1/21/07, 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 ---
**Author:** ![Allen\_Ingling](https://avatars.discourse-cdn.com/v4/letter/a/a183cd/32.png) [@Allen\_Ingling](https://psychtoolbox.discourse.group/u/Allen_Ingling)\ **Post date:** [February 12, 2007, 6:23am UTC](https://psychtoolbox.discourse.group/t/fwd-800-rectangles/1221/8 "2007-02-12T06:23:44Z")
On 2/11/07, Mario Kleiner \<[mario.kleiner@...](mailto: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 ---
**Author:** ![Allen\_Ingling](https://avatars.discourse-cdn.com/v4/letter/a/a183cd/32.png) [@Allen\_Ingling](https://psychtoolbox.discourse.group/u/Allen_Ingling)\ **Post date:** [February 12, 2007, 7:03pm UTC](https://psychtoolbox.discourse.group/t/fwd-800-rectangles/1221/9 "2007-02-12T19:03:21Z")
On 2/11/07, Mario Kleiner \<[mario.kleiner@...](mailto: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 ---
**Author:** ![saminverso](https://avatars.discourse-cdn.com/v4/letter/s/ed655f/32.png) [@saminverso](https://psychtoolbox.discourse.group/u/saminverso)\ **Post date:** [March 27, 2007, 3:33am UTC](https://psychtoolbox.discourse.group/t/fwd-800-rectangles/1221/10 "2007-03-27T03:33:00Z")
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](mailto:psychtoolbox@yahoogroups.com), "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](mailto:psychtoolbox@yahoogroups.com), "Andreas Kotowicz" \ wrote: > \> \> > \> \> On 2/11/07, 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 > \> \> > \> ---
**Author:** ![mariokleiner](https://avatars.discourse-cdn.com/v4/letter/m/13edae/32.png) [@mariokleiner](https://psychtoolbox.discourse.group/u/mariokleiner)\ **Post date:** [March 29, 2007, 2:21am UTC](https://psychtoolbox.discourse.group/t/fwd-800-rectangles/1221/11 "2007-03-29T02:21:06Z")
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](mailto:psychtoolbox@yahoogroups.com), "Samuel 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](mailto:psychtoolbox@yahoogroups.com), "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](mailto:psychtoolbox@yahoogroups.com), "Andreas Kotowicz" \ > \> wrote: > \> \> \> > \> \> \> On 2/11/07, 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 > \> \> \> > \> \> > \> ---
**Author:** ![mariokleiner](https://avatars.discourse-cdn.com/v4/letter/m/13edae/32.png) [@mariokleiner](https://psychtoolbox.discourse.group/u/mariokleiner)\ **Post date:** [March 29, 2007, 2:21am UTC](https://psychtoolbox.discourse.group/t/fwd-800-rectangles/1221/12 "2007-03-29T02:21:06Z")
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](mailto:psychtoolbox@yahoogroups.com), "Samuel 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](mailto:psychtoolbox@yahoogroups.com), "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](mailto:psychtoolbox@yahoogroups.com), "Andreas Kotowicz" \ > \> wrote: > \> \> \> > \> \> \> On 2/11/07, 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 > \> \> \> > \> \> > \> ---
**Author:** ![mariokleiner](https://avatars.discourse-cdn.com/v4/letter/m/13edae/32.png) [@mariokleiner](https://psychtoolbox.discourse.group/u/mariokleiner)\ **Post date:** [March 29, 2007, 2:21am UTC](https://psychtoolbox.discourse.group/t/fwd-800-rectangles/1221/13 "2007-03-29T02:21:06Z")
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](mailto:psychtoolbox@yahoogroups.com), "Samuel 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](mailto:psychtoolbox@yahoogroups.com), "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](mailto:psychtoolbox@yahoogroups.com), "Andreas Kotowicz" \ > \> wrote: > \> \> \> > \> \> \> On 2/11/07, 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 > \> \> \> > \> \> > \> ---
**Author:** ![mariokleiner](https://avatars.discourse-cdn.com/v4/letter/m/13edae/32.png) [@mariokleiner](https://psychtoolbox.discourse.group/u/mariokleiner)\ **Post date:** [March 29, 2007, 2:21am UTC](https://psychtoolbox.discourse.group/t/fwd-800-rectangles/1221/14 "2007-03-29T02:21:06Z")
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](mailto:psychtoolbox@yahoogroups.com), "Samuel 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](mailto:psychtoolbox@yahoogroups.com), "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](mailto:psychtoolbox@yahoogroups.com), "Andreas Kotowicz" \ > \> wrote: > \> \> \> > \> \> \> On 2/11/07, 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 > \> \> \> > \> \> > \> ---
**Author:** ![saminverso](https://avatars.discourse-cdn.com/v4/letter/s/ed655f/32.png) [@saminverso](https://psychtoolbox.discourse.group/u/saminverso)\ **Post date:** [March 29, 2007, 5:14am UTC](https://psychtoolbox.discourse.group/t/fwd-800-rectangles/1221/15 "2007-03-29T05:14:28Z")
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](mailto:psychtoolbox@yahoogroups.com), "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](mailto:psychtoolbox@yahoogroups.com), "Samuel 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](mailto:psychtoolbox@yahoogroups.com), "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](mailto:psychtoolbox@yahoogroups.com), "Andreas Kotowicz" \ > \> \> wrote: > \> \> \> \> > \> \> \> \> On 2/11/07, 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 > \> \> \> \> > \> \> \> > \> \> > \> ---
**Author:** ![mariokleiner](https://avatars.discourse-cdn.com/v4/letter/m/13edae/32.png) [@mariokleiner](https://psychtoolbox.discourse.group/u/mariokleiner)\ **Post date:** [March 29, 2007, 2:21am UTC](https://psychtoolbox.discourse.group/t/fwd-800-rectangles/1221/16 "2007-03-29T02:21:06Z")
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](mailto:psychtoolbox@yahoogroups.com), "Samuel 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](mailto:psychtoolbox@yahoogroups.com), "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](mailto:psychtoolbox@yahoogroups.com), "Andreas Kotowicz" \ > \> wrote: > \> \> \> > \> \> \> On 2/11/07, 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 > \> \> \> > \> \> > \> ---
**Author:** ![saminverso](https://avatars.discourse-cdn.com/v4/letter/s/ed655f/32.png) [@saminverso](https://psychtoolbox.discourse.group/u/saminverso)\ **Post date:** [March 29, 2007, 5:14am UTC](https://psychtoolbox.discourse.group/t/fwd-800-rectangles/1221/17 "2007-03-29T05:14:28Z")
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](mailto:psychtoolbox@yahoogroups.com), "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](mailto:psychtoolbox@yahoogroups.com), "Samuel 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](mailto:psychtoolbox@yahoogroups.com), "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](mailto:psychtoolbox@yahoogroups.com), "Andreas Kotowicz" \ > \> \> wrote: > \> \> \> \> > \> \> \> \> On 2/11/07, 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 > \> \> \> \> > \> \> \> > \> \> > \>