Ok. I remember I have seen a comment on the help mailing list of someone who observed this bug as I do (I doubt I can find the post though). Just to try to make myself clear: the delay I observe is between the click (buttondown) and the first time mouse movements lead to an effect (drawing zoombox of panning or rotating).

As for the ButtonDownFilter pan object property, it will indeed have to be taken into account when we implement this feature.

>> Matlab also doesn't execute ButtonDownFcn callbacks by default if one of the figure modes (pan, zoom, or rotate3d) is selected.

I guess this answers my question. We have a "select_object" method which can be called to decide what graphics object is under the mouse pointer when a click happens (this is what I called "full" selection) or it can also return only the axes object onto which the click happenned (much faster). If we don't need to honor the buttondownfcn (and thus the currentobject) in zoom/pan/rotate mode, then we can call the fast version.  I'll provide a patch.

With the Qt toolkit, and especially when the size of the figure window is large, starting drawing a zoom box or panning an axes is slow. Steps to reproduce

hf = figure (); clf;
sombrero;
pan on
## Resize the figure window so that it is as large as the screen
## Try to start panning
## -> It takes 1-2 seconds before mouse movements lead to the desired effect

This time lag is not observed with the fltk toolkit.
The problem is that when clicking inside a Qt figure we determine what object was under the mouse. This "full" selection operation takes much time, even more for large figures, and I think it is unnecessary since I don't expect the currentobject to be modified while we are using Pan, Zoom, Text or Rotate mouse modes.

If you agree with the above, I'll provide a patch that fixes the issue by avoiding the full selection step.