Chromeless non-fullscreen window in WinXP?

1
I have a bit of a conundrum here regarding an experiment I'm doing in
anaglyph. Basically I'm drawing a random dot stereogram with ~100 dots
at 85Hz at 1600x1024 resolution and it's missing all presentation
deadlines. I'm using the 9 stereo mode and kPsychNeedFastBackingStore
so that I can adjust the red and blue intensities for each eye. I'm
only drawing in the center of the screen in an area about 512x512.

Now if instead of opening a full-screen window I use a rect of 512x512
in OpenWindow it runs in realtime, that is, it's not missing the
presentation deadlines. So it appears that it's blitting parts of the
screen that don't actually need to be refreshed on every frame. Thus
the solution appears to be: 1) lower the resolution or 2) use a
non-fullscreen window. However, if I use solution 1), then my pixels
get bigger and I can't correctly adjust stereo disparity, so that's a
no-go. Solution 2) looks like it would work; the problem is that I see
the standard blue chrome of Windows around the window, and that is
highly distracting for the task at hand. If the non-fullscreen window
would be chromeless, then I could present the window above a blank
desktop and it would look just like the fullscreen scenario but it
wouldn't miss deadlines.

Apart from getting a new monitor/video card, how can I make this
experiment run in real time?

Patrick
2
Ok, here comes a hack that worked on OS/X. The imaging pipeline
is pretty configurable at runtime, so try this:

1. Add a InitializeMatlabOpenGL(0,0,1); at the top of your script, before
the first Screen command.

2. Before your trial loop, clear out the whole screen to background
color via two or three successive Screen('Flip', win); commands...

3. Then (still before entering the trial loop) add this code:

Screen('HookFunction', win, 'PrependMFunction', 'StereoCompositingBlit', 'ROI-Scissor
define', 'glScissor((1600-512)/2, (1024-512)/2, 512, 512);');
Screen('HookFunction', win, 'PrependMFunction', 'StereoCompositingBlit', 'ROI-Scissor on',
'glEnable(3089);');
Screen('HookFunction', win, 'AppendMFunction', 'StereoCompositingBlit', 'ROI-Scissor off',
'glDisable(3089);');

This reconfigures the imaging pipelines stereo compositor to restrict
pixel processing to some ROI with (x,y) start at ((1600-512)/2, (1024-512)/2)
and a width x height of 512 by 512.

Should safe some processing time for stereo computation. You could also
set the optional 'dontclear' flag of Screen('Flip') to 1 in order to prevent
Flip from automatically clearing the *full* framebuffer after a flip and
then use Screen('FillRect') to only clear out the 512x512 rectangle of
interest before drawing each frame. That might safe some extra hundred
microseconds by avoiding clearing of areas that haven't changed anyways.

And parse through all the performance tuning tips in the FAQ section of
our Wiki for more opportunities for optimization.

What gfx-hardware do you use?

I'll add some elegant way to restrict pixel processing in a future release,
this sounds like a generally useful feature, given how often a stimulus
only covers a small portion of the screen.

Tell me if it worked,
-mario


--- In psychtoolbox@yahoogroups.com, "Patrick Mineault" <patrick.mineault@...> wrote:
>
> I have a bit of a conundrum here regarding an experiment I'm doing in
> anaglyph. Basically I'm drawing a random dot stereogram with ~100 dots
> at 85Hz at 1600x1024 resolution and it's missing all presentation
> deadlines. I'm using the 9 stereo mode and kPsychNeedFastBackingStore
> so that I can adjust the red and blue intensities for each eye. I'm
> only drawing in the center of the screen in an area about 512x512.
>
> Now if instead of opening a full-screen window I use a rect of 512x512
> in OpenWindow it runs in realtime, that is, it's not missing the
> presentation deadlines. So it appears that it's blitting parts of the
> screen that don't actually need to be refreshed on every frame. Thus
> the solution appears to be: 1) lower the resolution or 2) use a
> non-fullscreen window. However, if I use solution 1), then my pixels
> get bigger and I can't correctly adjust stereo disparity, so that's a
> no-go. Solution 2) looks like it would work; the problem is that I see
> the standard blue chrome of Windows around the window, and that is
> highly distracting for the task at hand. If the non-fullscreen window
> would be chromeless, then I could present the window above a blank
> desktop and it would look just like the fullscreen scenario but it
> wouldn't miss deadlines.
>
> Apart from getting a new monitor/video card, how can I make this
> experiment run in real time?
>
> Patrick
>