We (Apple developers) run the latest Mac OS (10.7.1 as of 10/21/2011) with the latest version of Matlab (7.12) or (Linux developers) Ubuntu 64-bit (Gutsy) and 32-bit (Feisty) with Matlab 7.4 and the binaries are created to run on these systems. As noted above, some older versions (notably Matlab 14.1) are not able to use these mex files and crash when you try to run mglOpen. If this happens, then all you need to do is recompile MGL using mglMake(1).

The Matlab license manager checks every 30 seconds for the license. This can cause there to be an apparent frame glitch in your stimulus code, especially if you are using a network license (on our machines it can take ~200 ms to check for the license). The only known workaround to this is to run on a machine that has a local copy of the license. You can check this for yourself by seeing how long it takes to do screen refreshes:

 mglOpen;
 global MGL;
 checkTime = 30*MGL.frameRate;
 timeTaken = zeros(1,checkTime);
 mglFlush;
 for i = 1:checkTime
   flushStart = mglGetSecs;
   mglFlush;
   timeTaken(i) = mglGetSecs(flushStart);
 end 
 mglClose;
 plot((1:checkTime)/MGL.frameRate,timeTaken);
 zoom on;xlabel('seconds');ylabel('Frame refresh time (seconds)');

If you have the same problem, you should see one large spike in the time course like this:

This one shows it taking about 65 ms. Note that you may see small deviations in which one frame takes longer and then the following frame takes shorter than the mean. These are normal flucations persumably due to multi-tasking and other events that are intermittently taking up time. As long as these are shorter than a frame refresh interval minus the time it takes you to process the stimuli for your display, you will not drop any frames. Note that in the above code, if you change mglFlush to any other command, such as WaitSecs(1/frameRate);, you will still see the big spike for the license manager check–confirming that this has nothing to do with drawing to the screen.

Note that only version 1.5 supports linux, version 2.0 and beyond do not have linux support at the moment (actually could be supported with a little bit of work, if someone is interested in putting in the effort).

The list of funcitons not supported yet on linux for version 1.5 are:

• mglText
• mglTextDraw
• mglPlaySound
• mglInstallSound
• mglDescribeDisplays
• mglSwitchDisplay
• mglListener

If you want to use text under the linux operating system, you can use mglStrokeText.

Here is a more recent update from Jonas about the Linux version:

I am in the process of upgrading the Linux version of MGL to run under Ubuntu (64-bit and 32-bit) with NVIDIA and ATI graphics cards. Although the upgrade is still incomplete, most functions work equally well under Linux at this stage. Some differences that will remain between the platforms are listed below.

• no support for font-based text - this needs to be upgraded, I started looking into using FreeType for this which is widely available and would be easy to implement in the same texture-based way that the Mac code relies on. Care must be taken to ensure that the code is maximally portable across platforms, so it may be that some Mac-specific idiosyncracies need to be modified
• note that the stroke text works perfectly under Linux, so unless you are very enamoured with a specific font this is a perfectly usable workaround (though some symbols, eg %, are missing currently)
• some differences in the way you specify special keys, but this is generally to Linux' advantage - eg you can use ESC, BACKSPACE etc as names (relies on the XKeySymDef.h or sth like that)
• timing is in general more accurate on Linux, since the clock rate is much higher on modern systems (100-500Hz vs 60Hz on the Mac)
• no parallel port interface yet so you can't use Justin's code for calibration
• no sound - need to decide on a standard to use that is most widely available
• the syncing with OpenGL is idiosyncratic and depends on the graphics card. I have implemented this to use both the SGI video sync extension and the environment variable (both NVIDIA and ATI provide this option). The former is not supported by all OpenGL cards (though most modern ones) and can interact with the environment variable option, so I will make the latter the default, with an option to use the SGI extension when compiling only.

For the time being, only NVIDIA and ATI cards will be supported (because I only have access to those two machines).

• setting screen size and resolution requires the XRandR extension, which is supported on recent X distributions (Xorg 7.0 and later). Older X servers (eg Apple's X11) won't work.
• you need to reuse the X display or you run into memory problems, and the code for doing this needs to be checked for consistency. This is similar to the Mac window situation and relates to the uneasy relationship between Matlab and X. When you open a window, the MGL global variable will contain a window and display pointer that is used on subsequent calls; care must be taken not to clear the MGL variable between calls (once you do so, running MGL is likely to crash Matlab, even if you run clear all, which correctly closes the display).

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

If you are trying to compile on Mac OS X and are running into problems, try the following. First, make sure that you have Xcode properly installed. Next make sure your software is up-to-date, we generally compile with the latest version of Mac OS X (10.6.6 as of this writing 2/4/2011) and the latest version of Matlab (7.11 64bit). Next, check that you have the SDK for 10.5 installed properly (this should be installed when you install Xcode):

/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/

If you only have the 10.6.sdk installed, you may be able to edit the “mexopts.sh” file in the mgl/mgllib directory to link to 10.6 instead of 10.5. Change the following lines appropriately to link to 10.6:

SDKROOT='/Developer/SDKs/MacOSX10.5.sdk'
MACOSX_DEPLOYMENT_TARGET='10.5'

Note that mglMake should now work on Lion 10.7. To do so, we have added functionality to mglMake which swaps out the mexopts.sh file so that we use the new SDK 10.7.sdk, properly on Lion but not on older platforms.

If you have problems updating with SVN because you have changed files, you might be running into file or tree conflicts. See here for more info.

I have run into some unresolvable conflicts with the following error:

svn: GET of '/svn/mgl/!svn/bc/946/trunk/mgllib/mglEyelink/mglPrivateEyelinkReadEDF.c': Could not read response body: connection was closed by server (http://gru.brain.riken.jp)

You may try to svn checkout the whole repository again (remember to make a copy of your current repository and then copy back the files you have changed). It seems that this can be caused by Apache timing out for long updates, but that doesn't seem to be the reason why we are getting that (we have set out timeout very long and this happens for single files and always at the same place in certain revisions). I suspect that it is some problem with the Mac Apache svn/PHP module, but have not been able to figure it out. A workaround is to use svn+ssh for accessing the repository, but this is only for developers who have an account on our server gru.brain.riken.jp (email to justin if you think you need this). Also, if someone knows what the problem is and can provide a fix, let us know.

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.