Loss of keyboard and mouse events. This is resolved by going to System Preferences/Security & Privacy/Privacy/Accessibility and removing Terminal (uncheck) and then adding it back (check).

In matlab 2016 there was a problem opening CGL screens (the default). This has been resolved by forcing open via cocoa by doing mglSetParam('useCGL',0) in mglOpen when it detects that Matlab 2016 or greater is being used. Also made some changes to mglPrivateOpen to handle opening of the full screen context better. Did not add the binary to keep backwards compatibility, so you can either recompile:

mglMake mglPrivateOpen.c

Or download the precompiled version and place the file into mgl/mgllib.

There was an incompatibility issue with Matlab2013a on Mac OS (the full screen contexts showed up in black and drawing to the screen did not work. Turned out it had to do with a deprecated call to

CGLSetFullScreen( contextObj ) ;

Which in matlab2013a (MacOS 10.8) had to be replaced with:

CGLSetFullScreenOnDisplay( contextObj, displayMask );

This call is also deprecated in 10.8, so eventually may have to be replaced as well to keep CGL windows working. But cocoa windows full-screen now work well (this was fixed) and can be accessed by doing:

mglSetParam('useCGL',0);

You can also spoof a full screen (this just makes a window of the correct size without taking over drawing from other applications, by doing the following after setting useCGL to 0:

mglSetParam('spoofFullScreen',1);

Where you can set spoofFullScreen to the number of the window you want to open. After doing this, your calls to mglOpen or initScreen will bring up a windowed context that is the right size to cover your full display (try for instance, running mglTestTex and things should work as expected). Note that the task and menu bar may still be open in front of your MGL display. Either click on the MGL window to bring it to the front or set the Menu/Task bar to display on some other screen.

This issue had been resolved, but if you find you are still having problems, here is what the issue was and how to resolve it:

On Mac OS X there seems to be some interaction with having mutliple threads in the workspace that causes working within a window (i.e. mglOpen(0) as opposed to fullscreen) to be unstable. The workaround for now is not to close the window once it is opened. This seems to work fairly well. When one is completely finished working with the window, one can call mglPrivateClose to close the window. But after that, calling mglOpen(0) is likely to crash.

mglOpen(0) works fine if running matlab -nojvm or -nodesktop.

This has been resolved. On Mac OS X if you want to get key press events, you can get them with a system (nanosecond precision) time stamp in mgl 2.0. For the previous version of mgl you could only get them with a resolution of 1/60 second. If you are willing to sit in a loop testing the keyboard, you can use mglGetKeys and get acceptable time resolution (your time resolution will depend on how fast you poll the keyboard status). On Linux, the time resolution depends on the kernel's hard-coded HZ setting, which is usually between 100-500; the value can be retrieved (at least on Ubuntu) by typing cat /boot/config-`uname -r` | grep '^CONFIG_HZ=' The time resolution is 1/HZ sec; so on the current developer system, with HZ=250, key presses can be timed with a resolution of 1/250=4msec.

The default version of mgl runs on 64 bit Matlab. An older version (v1.5) will only run on 32-bit Matlab.

If you have Matlab 7.9 or greater installed, matlab defaults to running in 64 bit mode, but you can set it to run in 32 bit mode - though with the current version of mgl you do not need to do this:

1. Finder Go find the Matlab executable (somewhere like: /Applications/MATLAB_R2009b.app/bin/matlab) then click on it and “Get Info” by selecting and hitting “Command-I”. Then click “Start in 32-bit mode”.
2. Command line Run using a flag: matlab -maci

An issue about syncing to the vertical sync (i.e. mglFlush returns immediately rather than waiting for the vertical blank) using ATI videocards reported by Romesh Kumbhani and Gauri Wable. This appears to have been solved by a Mac OS update - it occurred for machines with 10.6.8 and no longer seems to be an issue for 10.7.4. We are not sure when it was fixed, but it seems that if you do:

>> [displayInfo, computerInfo] = mglDescribeDisplays;
>> computerInfo.openGL

ans = 

           Version: '2.1 ATI-7.18.18'
            Vendor: 'ATI Technologies Inc.'
          Renderer: 'ATI Radeon HD 5770 OpenGL Engine'
    MaxTextureSize: 16384
            Visual: ''
          Software: 0
        Extensions: {134x1 cell}

Machines that say the OpenGL version is 7.18.18 do not have the bug. If you are experiencing the problem, there are details below and a few solutions (although probably the best is just to update your OS).

The issue isn't an mgl specific issue, but is true with any program that uses OpenGL on recent Macs with ATI videocards (Radeon HD 5xxxx). We believe the problem is that video card driver isn't reporting back to OpenGL when a Vertical Blank has occurred. Obviously the video card is generating the VBLs (or the display would be desynchronized), but this information isn't getting back to OpenGL. Instead of OpenGL flushing the buffer and waiting for the VBL signal to occur, it's returning as soon as it can.

As far as we can tell people are having issues with mgl, psychophysics toolbox, expo, etc.. (all which rely on OpenGL working properly).

You can test for this, by running the program:

mglTestRefresh

It should return the expected refresh rate, but will return faster if you have the issue.

We have implemented one work around to this which is to spoof the vertical blank time by waiting the appropriate amount of time after mglFlush (this is implemented with the function mglFlushAndWait). You can set this for your display (if you are using the task code) by setting simulateVerticalBlank to true in mglEditScreenParams.

Another possible work around is to use an older video card (which probably calls on older drivers). We're currently using ATI Radeon HD 2600 XTs in our MacPros. We haven't tested the HD 3xxx series or the HD 4xxxx series, but the HD 5xxx series seems to be broken. We also haven't tested any NVidia cards.

My guess is that OpenGL issues the command to wait for the vertical refresh signal but returns immediately because the video card either isn't communicating back when the screen has refreshed, or the drivers have a bug; it's hard to tell which one it is.

We've been using either Eizos or Iiyama CRT monitors running 1280×960@120Hz for display our stimuli. They're connected to the DVI port of the 5770 via a DVI-VGA connector made by ATI.

When we use an HD 2600 XT card (specs below), we dont' have any issues.

Also, we tried using an iMac i7 connected to an Iiyama CRT via Apple's mini-DisplayPort to VGA connector and had the same issues in mgl and expo (our software). It seems like cards that natively generate an analog signal seem to work great. Those that rely on DisplayPort→Analog converters (either internally on the card or externally via an adaptor) have issues.