>I have a question for you that I have hesitated to ask because I wanted toI am able to replicate the basic problem here, although I didn't check
>fix it on my own, but I am beginning to believe it might be a program bug as
>I have been unable to solve the problem.
>
>I am having a problem displaying stimuli on a 2nd monitor. I have two
>monitors on my Mac and when I display stimuli on the 2nd monitor a couple of
>the grayscale values reverse, but not all. This does not happen when I run
>the program on the 1st monitor.
>
>Specifically, one of the frames (I use the FrameRect command) is reversing
>it's color, but not all of the frames are reversing. And one piece of text
>(I use the DrawText command) is reversing, but none of the other text is
>reversing. In addition, one of my rectangles reverses colors on only the
>first trial. Very odd. Do you know anything about this problem?
>
>Attached is a short code that will show you the problem. Change the
>parameter at the beginning of the code called "whichscreen" between 0 and 1
>to see it run on the 1st and 2nd monitor respectively. When run on monitor 1
>it looks as it should, but when run on monitor 2 a couple colors are
>reversed.
into all the details. I have a hypothesis about what is wrong but it
will take some time to check it in detail and it may be some time
before I can do so. I also have a suggestion for a possible work-around,
although I haven't tried it.
The problem seems to occur when the various draw/frame commands are
used to write into the offscreen window. Those calls are made through
QuickDraw routines supplied by the MacOS. The OS really wants to
translate the color values passed to those routines based on its own
idea of pleasing color palettes. Our code does a lot of work trying to
prevent the OS from doing any translation, and this is well-tested
when you are writing to a real window. It is probably less well-tested
when writing to offscreen windows, and I suspect what is going on
is that the somehow the color palette for the main screen (screen 0)
is influencing the behavior of these calls even when the offscreen window
is associated with an auxiliary screen (e.g. screen 1). So I think
you have found a bug, or at least an undocumented limitation, in
the toolbox code.
Here is a workaround. Basically what you are doing is building up
some offscreen windows to be moved onto the screen on each
trial, and you're doing this by drawing directly into the offscreen
window. Instead, try making the patterns by drawing into a rect on the
onscreen window. Then when you're done, copy that rect into
the desired offscreen window. If you don't want the onscreen
window to show anything while this is going on, simply fill
the lookup table with a constant (e.g. theClut = bgColor*ones(256,3)).
This will make all the drawing invisible (since all frame buffer
values get mapped to the same RGB triplet) but the drawing should
still work properly. Since it is already required that the onscreen
window be open when you use associated offscreen windows, I think
this workaround should not introduce any functional restrictions
as to what you can accomplish.
Let me know how it works. If it doesn't work, then something is
wrong with my thinking here and I'll try to delve into it further
to find you an acceptable workaround. At some point we'll try
to track down the underlying problem and either fix it so your
original code actually works or else modify the documentation
to clearly state the necessary restrictions about use of offscreen
windows.
Thanks for bringing this to our attention!
David