Performance of uitable() within a uifigure() compared to the performance within a figure()

Currently I am trying to figure out why the performance of uitable() within a uifigure() is so bad, that it is not useable at all. I hope somebody can direct me in direction here.

Basically I just have a uitable() within a uifigure() and fill the table with a 2000x100 mat of numbers. The uitable becomes unuseable. If you scroll it lags like hell until it is all rendered again. If you select a cell it also lags until the cell selection is shown.

If you create a uitable() within a figure() and fill it with the same amount of data there are no problems at all. It is super responsive as it should be.

Here are two coding examples for a uitable() in a uifigure() and a uitable() in a figure().

Please let me know if I am missing anything here because the new uifigure() approach seems to be unuseable.

%% uifigure() test
% this table will lag while scrolling and clicking cells

% Create and stack magic data
data = magic(100);
data = repmat(data, 20, 1);

% create figure
f = uifigure('Name', 'Test');

% create a 1x1 layout
g = uigridlayout(f);
g.RowHeight = {'1x'};
g.ColumnWidth = {'1x'};

% create table
dataTable = uitable(g);

% add data to table
dataTable.Data = data;

%% figure() test
% this table can be used without any lag

% Create and stack magic data
data = magic(100);
data = repmat(data, 20, 1);

% create figure
f = figure('Name', 'Test');

% create table
dataTable = uitable(f);

% add data to table
dataTable.Data = data;

[Mario Malic]

It is common for uifigure components.

One thing I have noticed with the uitable is that, when I scroll it, it "renders" the data precision. Maybe it would affect if you pre-fill it to the correct type of data. Also, maybe you could use scroll during your data filling, if it takes long.

[Thomas Kötter]

So the solution is to not use uifigure() at all since the graphical elements are so slow and laggy that it makes the gui unuseable? I do not think this is the intended solution by Mathworks. Why would they develop a new way for graphical interfaces if it is not useable at all.

Problem is still relevant and I need a solution for this.

[Bruno Luong]

@Thomas Kötter I test your code and it is usable to me.

The difference is when I scroll wuth the scroll bar the content is blank but I soon as I stop the text appears again probably at 10 Hz rate refresh.

Perfecly fine to me, but it is clearly the uitable in figure is much more responsible and nicer to use.

[Thomas Kötter]

Thanks for testing it out! The fact that the table is blank while scrolling and it takes a noticeable timeframe to actually render the data makes it a horrible user experience in my opinion.

Until now we use the old figure() which renders instantly even while scrolling. If we switch to uifigure() and the the interface or parts of it lag and need time to render it is a downgrade.

Thanks for clarifying. I hope Mathworks will tackle this in the future since the slow UI was always one of the biggest problems with Matlab and we hoped it would get better with this new approach.

[Walter Roberson]

"Why would they develop a new way for graphical interfaces if it is not useable at all."

There is a saying, sometimes called "Poe's Law", which goes, "Never use version 1.0 of anything!"

Which is to say that Mathworks identified a technical and market need to redevelop the graphics interface and has been working on it since then. They did not set out to make a slow interface, but it can be difficult to predict how the various parts will affect performance. Mathworks has been improving performance as they go; if I recall correctly, R2022a is said to have notably better performance for a number of components.

I have not asked Mathworks what they will do if they decide that they cannot meet whatever performance target they have set. I doubt that they would answer me about that anyways.

[Thomas Kötter]

Thank you for the answer and provided information.

Hopefully in a future release things will get better. Until then I guess we stay with the old figure() approach and if uifigure() and it's elements get faster and better we can do the switch one day.

Thank you everybody for participating in this little discussion and trying to help me!

[Bruno Luong]

The performance issue is related to HG2 engine and technology behind it. It manifests in various forms since it appears in R2015, TMW improves it but it won't catch the HG1 anytime soon. It won't be solved in the next release IMO. Either it's acceptable for you either you would stay with the old system, like me.

What I find intestering and somewhat puzzeling in your question is that the container uifigure matters, and not really the uitable itself.

[Thomas Kötter]

I understand it like this (but I am not a professional in this topic):

figure() and uifigure() are working on a completly different framework underneath. If you use uitable() it automatically detects the type of figure/uifigure. If you use figure() as top parent it will spawn the oldschool, fast, reliable table. If you used uifigure() as top parent the new fancy but slow table will be created. The command is the same but it checks its top parent and does something totally different depending on that.

But I think you guys know way more about this than I do :) Thanks for the help.

Now we know that we can postpone our switch from figure() to uifigure() for quite some time. We maintain and develop a plattform which hosts several tools and has a pretty fancy gui. If we switch now this would not work at all since everything is way too slow with the new system.

Answer 1

[Shuba Nandini]

Hello,

I understand that you are facing problem with “uifigure” function, but this is a known issue, and my colleagues are already working on this and it might get fixed in the future release.

I hope this helps!

Regards,

Nandini