Potential bug in annotation('arrow') with Parent = gca when zoomed in far

There seems to be a bug in annotation('arrow') when its 'Parent' is set to an axis object, i.e. 'gca'. (I got the idea from a how-to on Stackoverflow)

AFAIK one can then use the 'Position' property to specify x0 and the direction or alternatively the start and end point by setting the vectors 'X' and 'Y' - in the graph's coordinate system, which is very convenient.

Matlab then also takes care of moving the annotation around when we use the pan and zoom tools.

The issue arises as soon as I zoom into a plot such that the delta between grid lines is about 0.05. Then the arrow tip (the triangle) and shaft (the line) begin to separate as can be seen in the screenshot (the red arrow has its 'Parent'-object set to the axis and the blue one's parent is the figure object - I use a coordinate transform to calculate the correct on-figure coordinate, but note what happens if this arrow's coordinates get outside the plot's limits... ugly...). Decreasing the arrow's length doesn't help. The separation stays the same.

I run Matlab R2016b/Win. Do you consider that as a bug?

Use the code below to play around with the behavior of the arrow objects. Simply use the pan and zoom tool on the plot.

figure;
h_axis =        subplot(1,1,1);

% Arrow whose parent is the subplot (axis object). Can use the coordinates
% directly.
x_ax = [0.3,0.5];
y_ax = [0.5,0.5];
h_arrow_axis =  annotation('arrow',x_ax,y_ax,'color',[1,0,0]);
set(h_arrow_axis,'parent',h_axis);

% Arrow whose parent is the figure. Need to transform its coordinates
% first.
x_fig = [0.7,0.5];
y_fig = [0.5,0.5];
[x_t,y_t] =     transform_coordinates(h_axis,x_fig,y_fig);
h_arrow_figure = annotation('arrow',x_t,y_t,'color',[0,0,1]);

% Create Callbacks to enable repositioning of the figure-arrow
p = pan;
p.ActionPostCallback  = {@pan_zoom_callback_update_arrow,h_axis,h_arrow_figure,x_fig,y_fig};
z = zoom;
z.ActionPostCallback  = {@pan_zoom_callback_update_arrow,h_axis,h_arrow_figure,x_fig,y_fig};

function pan_zoom_callback_update_arrow(~,~,axis_handle,arrow_handle,x,y)
    %
    [x_t,y_t] = transform_coordinates(axis_handle,x,y);
    arrow_handle.X = x_t;
    arrow_handle.Y = y_t;
end

function [xaf,yaf] = transform_coordinates(h_axis,x,y)
    % Excerpt from DS2NFU
    % Convert data space units into normalized figure units. 
    % By Michelle Hirsch

      %%Get limits
      axun = get(h_axis,'Units');
      set(h_axis,'Units','normalized');
      axpos = get(h_axis,'Position');
      axlim = axis(h_axis);
      axwidth = diff(axlim(1:2));
      axheight = diff(axlim(3:4));

      % Transform data
      xaf = (x-axlim(1))*axpos(3)/axwidth + axpos(1);
      yaf = (y-axlim(3))*axpos(4)/axheight + axpos(2);

      % Restore axes units
      set(h_axis,'Units',axun)
  end

[Jan]

Stefan, your report is impressingly nice and clear. +1

Answer 1

[Jan]

Bug

The problem can be reproduced on my R2016b/Win using this code:

figure;
h_axis = axes;
h_arrow_axis = annotation('arrow', [0.3,0.5], [0.5,0.5], 'color', [1,0,0]);
set(h_arrow_axis, 'parent', h_axis);

Then zoom in.

[Stefan Rickli]

Thanks for checking it and summarizing the reproduction steps.

Also could you tell me what's the standard procedure to report (potential) bugs?

First verify with the help of this forum and then file a bugreport on https://www.mathworks.com/support/bugreports (just found it right now) or directly file it there (because I got one more to post)?

[Jan]

Most of the found bugs are no bugs of the function, but a missunderstanding of the documentation. Therefore asking the forum is always a good idea, but not necessary. Your report is such clear, that it is obvious, that you have double-checked it already reliably. The MathWorks team gets many reports and the problem might be known already, such that they can answer very quickly.

I've compressed your code for reproducing the problem only to demonstrate that it is not caused by the smart pan and zoom ActionPostCallbacks.

I'm still waiting for the bug-bounty program! ;-)

[Stefan Rickli]

> Most of the found bugs are no bugs of the function, but a missunderstanding of the documentation.

Haha, that's kind of what happened for the second "bug" :-)

But it was rather misleading/outdated documentation so I reported that to Mathworks.

[Adam]

Just to confirm, this behaviour is the same in R2017a also.

[Leptoceratops]

I can confirm that this is the case with R2019b on MacOS 10.14.6