Why is it so slow to draw a figure in Matlab?

I just started learning Matlab.

I am drawing very simple function curves, like y=kx or y=sin(fx).

Then I am using a slide bar to change the values of k or f.

In softwares like Geogebra, or program I made using VB.net, the figure will change with the changing values without any delay.

But in Matlab, though the figure does change, there is an obvious delay, it seems the drawing takes a lot of time.

In Matlab, I tried to draw using Script, Live Script, App.

While changing the k or f values, I have tried to update the figure with 'plot' or 'fplot' directly, or to update with 'set' to change the 'yData' or 'Function'.

How can I speed up the drawing in Matlab?

What's causing this slow drawing?

[Walter Roberson]

Sometimes that can be caused by having poor graphics drivers. Are your drivers up to date?

[smarthu]

I am not sure whether my drivers are up to date.

But I think the drivers should be up to date for other programs since they are running fine.

So my question is how can make Matlab to use that driver?

And another thing is: I tested my problem on two different computers, one is laptop, another is a desktop, they both show the same problem.

[Walter Roberson]

What shows up for

opengl info

[smarthu]

>> opengl info

Version: '4.5.0 - Build 30.0.100.9865'

Vendor: 'Intel'

Renderer: 'Intel(R) HD Graphics 620'

RendererDriverVersion: '30.0.100.9865'

RendererDriverReleaseDate: '2021-08-20'

MaxTextureSize: 16384

Visual: 'Visual Effect 0x08，(RGBA 32 bit(8 8 8 8), Z Depth 16 bit, Hardware Acceleration, Double Buffer Zone, Anti-aliasing 8 times sampling)'

Software: 'false'

HardwareSupportLevel: 'full'

SupportsGraphicsSmoothing: 1

SupportsDepthPeelTransparency: 1

SupportsAlignVertexCenters: 1

Extensions: {240×1 cell}

MaxFrameBufferSize: 16384

[Walter Roberson]

https://www.intel.com/content/www/us/en/download/19344/intel-graphics-windows-dch-drivers.html

You are a little out of date on your graphics driver; I linked to the current installer.

[Jan]

It would be much easier to find problems of your code, if we can see the code. Maybe you create a new figure in each iteration, loose time with clf or cla etc. Please post your code to give us a chance to help.

[smarthu]

I press the button first to draw the initial curve. Then use the slider to change the value of v.

My code:

            properties (Access = private)
                fp % fplot figure
            end
        
            function ButtonPushed(app, event)
                v=app.vSlider.Value;
                app.fp=fplot(app.UIAxes,@(x) v*x);
            end
            
            function vSliderValueChanging(app, event)
                changingValue = event.Value;
                set(app.fp,"Function",@(x) changingValue*x);
            end
            

[Jonas]

did you try to add

drawnow limitrate;

directly after the plot command?

[smarthu]

Just tried it.

Before adding this, while moving the slider, many frames are not drawn.

After adding this, the chaging of figure is continuous, but takes longer time compared to the movement of slider.

[dpb]

fplot is a user-convenience function, not one built for performance. It does everything all over every time it is called; I wouldn't expect it to be very fast...easy, yes; high-performance, "not so much".

To get any speed here I think you'll need to create the graph/axes and directly recompute the ydata and replace it in the line handle or use line instead of plot

You might also try <animatedline> before jumping all the way to that level.

I also suspect it's the latency of the callbacks from the app contributing to more of the delay than the actual drawing; not sure there's much that can be done there. Or, there may be so many callbacks generated by moving the slider it overwhelms the compute power -- that's what the 'limirate' parameter on drawnow will take care of by throwing away a bunch of them. Whether there's any way to increase the granularity or reduce the number of callbacks on how much of a variation it takes to trigger a callback I don't know.

I'm guessing although I've done almost nothing with the app GUI overall (and what I have done have nothing that has anything except static updates of input parameters like file name selection) so I just don't have any hands on experience that is truly applicable, but my guess here is one is seeing the inherent overhead in MATLAB.

There was another similar topic not too long ago -- an attempt to measure time a user kept the cursor inside a graphic area on the screen -- it was easy to move the mouse sufficiently fast to completely miss the event -- some machinations of the code as far as how it was done helped considerably, but it never got to be under a fair latency time. I dunno if I could find that topic again now or not...

<Answer_864425> is a demo of the above subject that shows 65 msec average latency to the response above -- the discussion there shows some "tricks" that were done from OPs original implementation that helped the response there; it was, of course reading the cursor position of a fixed graphic but it did have to compute the inside/outside decision. What would be a response time of a graphic update in that case I wonder...how much time would the graphics take as opposed to the latency?

[smarthu]

Yes, the line method draws much faster.

Now the figure changes as fast as I move the slider!

Thanks!

[dpb]

Ah, so! I was certain it would help, not so sure it would be a total solution...

Answer 1

[Prateek Rai]

Hi,

To my understanding, you are attempting to draw function curves with a parameter whose value depends on a slide bar.

Here is the possible workaround:

You can create Live Editor in MATLAB and divide the whole code into 2 sections:

1. Part 1: Where setup of the entire graph is placed
2. Part 2: Where actual changing of parameter and plotting of graph is placed

It will look like:

Section 1

%% Sine Wave plot
%% Time specifications:
   Fs = 8000;                   % samples per second
   dt = 1/Fs;                   % seconds per sample
   StopTime = 0.25;             % seconds
   t = (0:dt:StopTime-dt)';     % seconds 

%% F and x specifications:
   Fc = 60;
   x = 2*pi*Fc*t;

Section 2

 k = k-7-1010-7 %% this represents Numeric Slider in Live Task

k = -7

   y = sin(k*x);
   % Plot the signal versus time:
   figure;
   plot(t,y);
   xlabel('time (in seconds)');
   title('Signal versus Time');
   zoom xon;

By doing so,

If you change the 'k' value using slider, only graph and plot part will get affected and thus will update the graph fast.

On a similar note, if you want to just make a small part of code dynamic then try to keep it in a separate section in live editor to get faster execution.

You can refer to the following MathWorks Documentation page to learn more about MATLAB Live Editor.

[smarthu]

I have already tried this method. It's slow compared to Geogebra.

In the comments above, dpb has already pointed out that methods like fplot will be slow.

And I have to use line method to draw the curve.

[dpb]

@smarthu -- did you never try animatedline and addpoints?