@Steven – you can use HTML formatting to achieve multi-line tooltips, as explained here.

 
tipString = sprintf('This is line 1\nThis is line 2');
javaMethodEDT('setToolTipText',jBtn,tipString);

@Malcolm – Thanks for the pointer. It appears to be a very useful function for heavily-laden GUIs.

You might wish to modify the sigtools link at the bottom of your demo to a blue-underlined hyperlink. I posted an article that discussed this in 2009, as well as some code and discussion on CSSM.

http://www.mathworks.com/matlabcentral/fileexchange/29913-mouse-motion-handler

MouseMotionHandler provides an alternative to chaining callbacks or having a lengthy switch block in a WindowButtonMotionFcn callback to manage mouse motion effects. MouseMotionHandler puts its own callback into a figure’s WindowButtonMotionFcn property. This callback manages the servicing of callbacks for other objects in the figure. It actively determines what is beneath the mouse then invokes a user-specified callback for that object, if one is set. Specify these objects and their mouse motion callbacks using the MouseMotionHandler add and put methods. MouseMotionHandler also extends the functionality of the standard WindowButtonMotionFcn callback: its internal logic discriminates between mouse entered, moved and exited calls.

Weird – you might be on to something, but for the life of me I am not seeing where the recursion is happening. Actually, I’m getting the feeling “overhead” is taking into consideration the time the GUI is usingto draw/refresh objects.

If I replace all callbacks the GUI does with a function that draws/updates nothing to the screen (writes to the command window), the overhead of the events drops to nothing. Yet if I tie it to the GUI updating callbacks, the only thing listed in the event and callback function is overhead.

Maybe I need to look at a different way to draw the objects to the screen? I’m already re-using object handles, so I’m not sure how much more optimized it can be – haha.

I guess I’ll keep digging. Thank you for the insight.

@Thomas – I suspect a case of endless recursion due to the contained object’s listener triggering its parent which triggers back the child and so on until you reach your recursion limit (or something similar to that effect).

To test this hypothesis, try triggering some entirely external Matlab function (i.e., a function outside any class) and see whether the overhead remains. If my hunch is correct, then you’ll see the overhead disappear. If not, then you’ll have a very simple example to submit with your bug report to isupport@mathworks.com.

There are several ways to fix such recursive triggering. Here is a simple bare-bones implementation that you can use:

function myCallbackFunc(hObject,hEventData,varargin)
  persistent inCallback
  try
    if ~isempty(inCallback)
      return;   % we're already in this callback: bail out
    else
      inCallback=1;
    end
    % The actual callback processing is done here 
  catch
     % Do some cleanup here
  end
  inCallback = [];

It’s a real shame too since the event/listener construct is a really elegant way to make one’s objects interface-agnostic in a model-viewer relationship. To give you an idea of scale, I have 50 objects with 3 events each being listened to by a single viewer.

Does anyone know of a way to speed up the event/listener overhead or make the profile cough up what ‘overhead’ is actually taking so long?