plot is blinking when clearing figure

I'm doing a project related to sending/receiving via udp port. Currently, I'm doing the project based on two MATLAB sessions. Both sessions plot data, but one of the sessions, the plot is blinking when I use clf or delete YData. I can't create a minimal working example but the following code captures the most important lines in the code. I've done some research and one states that `pause()` triggers screen update which may cause the issue, but I'm not sure about it. Any suggestions?

for i = 1:numel(t)
    % method 1 to clear figure
	%clf
    
    % method 2 to clear figure
    hndl=get(gcf);
    hndl.YData=[];
    axis([0 6 -1 5])
    hold on

    % send control input to slave robot
    writeline(u1,input,"XXX",8866);
    
    % get observations from slave robot
    if u1.NumBytesAvailable ~= 0
    	data = readline(u1);
    end
    flush(u1); % <--- flush udp input/output buffers

    % method1 is object of handle class
    method1.draw1;  % contains plot()
    method1.draw2;  % contains plot() & viscircles()
    method1.draw3;  % contains plot()
    method1.draw4;  % contains plot()

    hold off
    pause(.2)
end

Answer 1

[Walter Roberson]

hndl=get(gcf);

gcf() returns a figure handle. get() applied to it returns a struct of property values, and does not return the handle itself.

hndl.YData=[];

You are taking the struct of information returned from above, and setting the YData field of the struct to empty. But figures do not have a YData field, so this is creating a new YData field in the struct. If figures did have a YData field... then making that assignment would be overwriting the information structure, not changing the properties of the figure.

YData is a property of a number of different kinds of graphics objects, such as surfaces and line plots. Setting one YData for an object in the figure would affect only that one object, rather than clearing the axes or the figure.

You could do

objs = findobj(gcf, '-property', 'YData');
set(objs, 'YData', [])

but that doesn't really clear the figure either: it would leave some objects in place and would make other objects invisible without deleting them.

[Bandar]

How to solve this issue?

[Walter Roberson]

Ideally, have each of the methods update a graphics object instead of creating a new graphics object.

function draw1
   persistent h1
   if ~isvalid(h1)
      h1 = appropriate plot call;
   else
      h1.XData = new x data;
      h1.YData = new y data;
   end
end

[Bandar]

I got error "Check for incorrect argument data type or missing argument in call to function 'isvalid'."

[Walter Roberson]

Yes. In that case you would not use persistent .

Just make sure to initialize it to gobjects(1) . Oh, and use ishghandle() insted of isvalid()

[Bandar]

This solution will force me to have gobjects for each thing that needs to be drawn. In my simulation, the robot nagivates and detects beacons. So numbers of beacons are not known a priori. Is there a better approach? I'm thinking to have a global Line object and use it with plot() (i.e. using hold on).

[Walter Roberson]

The robot needs to understand persistence of objects if it has to be able to deal with motion of objects.

The robot also has to understand persistence of objects if it needs to be able to backtrack -- which will be the case if it does not have global knowledge. Robot approaches a junction, has to make a decision about which way to turn given limited knowledge, and turns out to turn the wrong way (perhaps that route is only possible part of the time due to something not visible from the junction.) If the robot does not have persistent memory of objects, then when the robot backs up to the junction and has to make a decision about which way to go, the robot would make the same mistake.

So upon the first detection of an object, in the data structure that represents the object, create a gobject (or vector of gobject) to draw the object.

Each step, robot checks its surroundings, figures out that objects are visible, matches them against predictions of the locations of objects it knows, figures out it already knows the object: it can now update the graphics object stored along side the object.

If you do not want to keep a gobject around indefinitely for each object ever observed, then record a "time" of some sort with each gobject, and then each time the gobject is "used" (determined to be within view), update the time; occasionally purge the gobjects that have not been used for a while.