uifigure vs figure - advice please

We have a set of Matlab-based tools that all use a common set of GUI superclasses to provide a consistent look and feel plus certain common functionality. They pre-date uifigure so use figure to create the GUIs. There are some features that are only available in GUIs created using uifigure, e.g. scrollable panels, plus the compatibility with the App Designer.

As a test I changed our superclass to use uifigure and encountered a pile of warnings and errors when testing with one of our tools. Obviously I can work through those but expect I will find the same in our other tools using the same GUI superclasses.

So, my questions are:

1) Is there a guide specifically for converting figure-based GUIs to uifigure-based? A checklist of what properties/methods are different even. I couldn't find anything.

2) Any experience/comments on how much pain is involved? If it was just one tool I'd go for it but it's a suite of tools in our case.

[Walter Roberson]

https://www.mathworks.com/matlabcentral/fileexchange/66087-guide-to-app-designer-migration-tool-for-matlab

[Justin]

Thanks, there is some useful info there, although it is for GUIs created with GUIDE rather than created programatically.

[Mario Malic]

This will be hard to answer for any of us, especially since you're talking about your own, specific class that you use to create GUIs. You can open uifigure and figure properties documentation side by side, you'll see that most of the properties are the different, also, how callbacks are written is different (I am not completely sure about this one, as I didn't write any for figure). Secondly, there might be an issue with the components that support figure but not uifigure. This doesn't seem like an easy task to do.

[Justin]

I wasn't expecting a definitive answer so your thoughts were appreciated. It didn't seem trivial to me either and it was useful to have that confirmed.

It turned out that implementing a custom scrollable uitab in my existing figure-based GUI wasn't so difficult, so I've done that for now.

Will look to move over to uifigure at a later date as no doubt its native scrollable containers will be better than mine.

[Adam Danz]

My $0.02 on this in a recent similar question: [here].

One of the biggest differences is the HandleVisibility between uifigure ('off') and regular figures ('on') which requires using parent handles when adding anything to the figure but this is a good habbit to get into, anyway.

UIaxes (and uifgures) are still a bit slower to render than regular axes/figure [see this comparison from r2019b]. That comparison includes a lot of overhead in appdesigner but the difference still exists outside of appdesigner.

As you mentioned, there are a lot of nice features designed for uifigures and if you plan on using those features, it may be tipping point to your decision. If you're not planning on using those features, I see no reason to make the switch.

Update

The differences between figure and uifigure have gradually decreased. See Jasmine's answer below for the most up to date info.

[dpb]

Jasmine's answer addresses syntax issues but doesn't have any information about the rendering speed issues discussed in your performance-testing thread, Adam. What is the state there and is there any hope for AppDesigner to ever perform even close to interactive?

I've built a couple of trivial applications for deployment that have no graphics at all and the startup time is abysmal plus even simply processing a couple relatively small Excel files to build a new cell array and then write it to another Excel file is like 3X as slow as running the same code interactively. Where are all those CPU cycles getting eaten up when compiled?

[Adam Danz]

Hi @dpb, while I can’t speak to any specifics, I just want you to know that performance will continue to be a primary focus. If you find any specific, reproducible performance regressions, pleaes do report them to tech support!

[dpb]

I don't know about regressions, Adam, owiing to it being such a pain with IT for the particular application I've stuck with R2022b in order to not have to go through the pain of having to reinstall on the Foundation machine to be able to work on it there as well as the home one. I suppose I could spawn a local branch and see how it would perform here in comparison to see if any improvements since would make it worth the trouble.

I can understand the load/startup time (although it would seem there could be a way to not have to load absolutely the whole runtime but just what the app needs), but I can't fathom why, once it is in memory, the execution time isn't essentially identical, not so much slower?

[dpb]

@Adam Danz -- Adam, I have to recant somewhat -- I have been comparing watching the app being used in the Foundation office in comparison to running it here and I cannot actually time the comparison there because MATLAB is not installed on those machines.

@Walter Roberson pointed out in another thread my supposition about JIT not being in play for the compiled app induced me to actually add timing code inside the app and I discovered that while it definitely is slower on those machines, on the same machine the two do perform very similarly...

Run  Compiled   Interactive Ratio
  1     41.65   31.35       1.32
  2     32.23   31.96       1.01
  3     32.36   31.47       1.03

was the result of that timing exercise, other than the first run the compiled code was a fair amount slower, the runtime otherwise is essentially the same.

So, if something could be done about the startup time and that seemingly interminable black hole after the double-click until finally!!! the splash screen appearsI(*), there wouldn't be much to complain about. <vbg>

(*) Even if there were only a spinning wheel or SOMETHING to let the user know it's working, it would go a long way. It's that big black hole of nothing that is so disconcerting.

[Adam Danz]

Glad to hear this! I'll pass your comment along.

[dpb]

I've built no Windows apps from code other than Fortran console computational code so I don't know anything about normal app startup without the console, but commercial applications don't have such a delay before their splash screen appears as do the MATLAB compiled apps so I infer there must be some manner to make that occur while the code is doing whatever else it needs to do before rendering the user interface. The ladies have finally (sorta') gotten adjusted to the idea they just have to wait, but it is still disconcerting because one cannot tell if the application has actually been started or not for several seconds (that seem like forever) so the inclination is to try again and again and again...and, sometimes, the double-click didn't actually happen, either, so have sat around waiting until do finally decide that is what happened. It's just not a user-friendly experience to use these apps with this behavior.

Answer 1

[Jasmine Poppick]

This page gives an overview of the steps for updating: Update figure-based app to Use uifigure.

There's also more information on each step. For example, this page talks about replacing uicontrol with the newer UI component functions: Update UIControl Objects and Callbacks.