- Customizing web-GUI uipanel
- Scrollable GUI panels
- Multi-threaded Mex
- Plot legend customization
- Sliders in Matlab GUI – part 2
- String/char compatibility
- Blocked wait with timeout for asynchronous events
- Speeding-up builtin Matlab functions – part 2
- Speeding-up builtin Matlab functions – part 1
- Spicing up the Matlab Editor
- Auto-scale image colors
- Adding custom properties to GUI objects
- IP address input control
- Customizing axes tick labels
- Desktop (43)
- Figure window (51)
- Guest bloggers (59)
- GUI (155)
- Handle graphics (82)
- Hidden property (41)
- Icons (7)
- Java (171)
- Listeners (22)
- Memory (16)
- Mex (13)
- Presumed future risk (379)
- Public presentation (6)
- Semi-documented feature (9)
- Semi-documented function (35)
- Stock Matlab function (137)
- Toolbox (9)
- UI controls (50)
- Uncategorized (13)
- Undocumented feature (205)
- Undocumented function (37)
TagsActiveX AppDesigner Callbacks COM Compiler Desktop Donn Shull Editor Figure FindJObj GUI GUIDE Handle graphics HG2 Hidden property HTML Icons Internal component Java JavaFrame JIDE JMI Listener Malcolm Lidierth MCOS Memory Menubar Mex Optical illusion Performance Profiler Pure Matlab schema schema.class schema.prop Semi-documented function Toolbar uicontrol uifigure UIInspect uitable uitools Undocumented feature Undocumented function Undocumented property
- Blake (12 hours 31 minutes ago): This is a great article! Does anyone know the format of the header information in the converted bytestream? Thanks!
- Yair Altman (14 hours 22 minutes ago): In recent Matlab releases, Matlab’s pause is no less (sometimes even more) accurate than Java’s Thread.sleep, with a consistent mean inaccuracy (overhead) of 0.1-0.2...
- Sometalk (16 hours 5 minutes ago): Have you rerun this benchmark more recently? I wonder if there have been any improvements in this space.
- Peng Zheng (1 day 9 hours ago): Hi Yair, I tried to run the example, and compiler the example(matlab 2017a), it works for a few minutes, but new problem appears, the exe crashed with a error，（jframe cannot...
- Dan (3 days 4 hours ago): Thank you so much. This works well for UITables embedded in a traditional figure but I’m having issues getting findjobj to work when the UITable is embedded in a UIFigure, it just...
- Joe Burgel (6 days 11 hours ago): Hi Yair, Once again, saving my life! Thanks so much for what you do for all these years.
- Sarah (7 days 9 hours ago): Thank you!
- Yaroslav (7 days 18 hours ago): @Mark, the zoom function calls resetplotview (undocumented). It, in turn, resets all modes (X/YLimMode) to auto. That is why the listeners do not trigger. To solve the issue, link...
- Mark D. (8 days 14 hours ago): @Yaroslav your solution works great, but the double mouseclick (of zoom out or zoom in), which puts the plot in the default optimized axes, doesn’t work or behaves the same,...
- Peter Cook (10 days 5 hours ago): Yair, One multithreaded mex file I can’t say enough good things about is getmatvar which, in addition to being faster than MATLAB builtins (i.e. matfile objects), allows...
- Jan Afridi (11 days 16 hours ago): Thanks for community referring. I wish this help to understand Matlab and resolve the issue that I am facing.
- David Sampson (12 days 17 hours ago): See also uix.ScrollingPanel in GUI Layout Toolbox. This works for figures (not uifigures) from R2014b onwards.
- Yair Altman (20 days 9 hours ago): @Royi – yes, but this is definitely not easy. Hopefully custom JS integration will be better in future Matlab versions. Perhaps I’ll post something similar to this...
- Yair Altman (20 days 9 hours ago): @Royi – I’m not familiar with any such control within Matlab, but you may possibly find such in one of the numerous online Java libraries (there were hundreds of...
Today I’d like to share a technique I’ve been experimenting with, allowing Matlab to respond to pretty much any JS event to which we can attach a listener. This is an overview of how it works:
- create a UIFigure with the desired contents, and add to it (at least) one more dummy control, which has an associated Matlab callback.
- execute a JS snippet that programmatically interacts with the dummy control, whenever some event-of-interest happens, causing the Matlab callback to fire.
- query the
webWindow, from within the Matlab callback, to retrieve any additional information (“payload”) that the JS passed.
This approach allows, for example, to easily respond to mouse events:
I would like to introduce guest blogger Khris Griffis. Today, Khris will continue the series of posts on web-based uifigure customization with an article showing how to create scrollable/customizable panels in web-based uifigures. This post follows last-week’s article, about placing controls/axes within a scroll-panel in non-web (Java-based) figures. Users interested in advanced aspects and insights on the development roadmap of web-based Matlab GUI should also read Loren Shure’s blog post from last week.
As a retinal physiologist, I spend a lot of time in Matlab creating GUIs to visualize and analyze electrophysiological data. The data often requires a lot of processing and quality control checks before it can be used for interpretation and publication. Consequently, I end up with many control elements taking up precious space on my GUI.
In Java-based (legacy/GUIDE) figures, this wasn’t a huge problem because, depending on what GUI components I needed, I could use a pure Matlab approach (a child panel within a parent panel, with a couple of control sliders moving the child panel around), or a number of Java approaches (which are always more fun; Yair described such an approach last week).
Unfortunately, the web-based (App-Designer) figure framework doesn’t support Java, and the pure/documented Matlab approach just doesn’t look good or function very well:
AppDesigner uislider is not a good scrollbar, no matter what we do to it!
<div> with a Matlab-designed CSS style. We can customize it with little effort.
The main goal here is to create a scrollable customizable uipanel containing many uicontrol elements, which could look something like this:
Matlab enables two types of GUI container types, via the Units property: fixed-size (
'chars', etc.) and flexible (
'normalized'). In many cases, we need something in between: a panel that expands dynamically when its container grows (i.e., flexible/
Scrollable Matlab GUI panel
I was recently asked by a consulting client to help speed up a Matlab process. Quite often there are various ways to improve the run-time, and in this particular case it turned out that the best option was to convert the core Matlab processing loop into a multi-threaded Mex function, while keeping the rest (vast majority of program code) in easy-to-maintain Matlab. This resulted in a 160x speedup (25 secs => 0.16 secs). Some of this speedup is attributed to C-code being faster in general than Matlab, another part is due to the multi-threading, and another due to in-place data manipulations that avoid costly memory access and re-allocations.
In today’s post I will share some of the insights relating to this MEX conversion, which could be adapted for many other similar use-cases. Additional Matlab speed-up techniques can be found in other performance-related posts on this website, as well in my book Accelerating MATLAB Performance.
There are quite a few online resources about creating Mex files, so I will not focus on this aspect. I’ll assume that the reader is already familiar with the concept of using Mex functions, which are simply dynamically-linked libraries that have a predefined entry-function syntax and predefined platform-specific extension. Instead, I’ll focus on how to create and debug a multi-threaded Mex function, so that it runs in parallel on all CPU cores.
The benefit of multi-threading is that threads are very light-weight objects, that have minimal performance and memory overheads. This contrasts to multi-tasking, which is what the Parallel Computing Toolbox currently does: launches duplicate copies of the entire Matlab engine process (“headless workers”) and then manages and coordinates the tasks to split up the processing work. Multi-tasking should be avoided wherever we can employ light-weight multi-threading instead. Unfortunately, Matlab does not currently have the ability to explicitly multi-thread Matlab code. But we can still use explicit multi-threading by invoking code in other languages, as I’ve already shown for Java, C# (and .NET in general), and C/C++. Today’s article will expand on the latter post (the one about C/C++ multi-threading), by showing a general framework for making a multi-threaded C-based Mex function.
Three years ago I explained how we can use a couple of undocumented hidden properties of the legend in order to add a legend title (the legend object had no Title property back then – this was only added in a later Matlab release, perhaps as a result of my post). Today I will expand on that article by explaining the plot legend’s internal graphics hierarchy, how we can access each of these components, and then how this information could be used to customize the separate legend components. Note that the discussion today is only relevant for HG2 legends (i.e. R2014b or newer).
Let’s start with a simple Matlab plot with a legend:
hold all; hLine1 = plot(1:5); hLine2 = plot(2:6); hLegend = legend([hLine1,hLine2], 'Location','SouthEast'); hLegend.Title.String = 'MyLegend';
Exactly 3 years ago I posted about various alternatives for embedding sliders in Matlab GUI. Today I will follow up on that post with a description of yet another undocumented builtin alternative – controllib.widget.Slider. A summary of the various alternatives can be seen in the following screenshot:
The controllib.widget.Slider component is a class in Matlab’s internal
controllib package (last week I discussed a different utility function in this package, controllib.internal.util.hString2Char).
In numerous functions that I wrote over the years, some input arguments were expected to be strings in the old sense, i.e. char arrays for example,
'off'. Matlab release R2016b introduced the concept of string objects, which can be created using the string function or [starting in R2017a] double quotes (
The problem is that I have numerous functions that supported the old char-based strings but not the new string objects. If someone tries to enter a string object (
"on") as input to a function that expects a char-array (
'on'), in many cases Matlab will error. This by itself is very unfortunate – I would have liked everything to be fully backward-compatible. But unfortunately this is not the case: MathWorks did invest effort in making the new strings backward-compatible to some degree (for example, graphic object property names/values and many internal functions that now accept either form as input). However, backward compatibility of strings is not 100% perfect.
In such cases, the only solution is to make the function accept both forms (char-arrays and string objects), for example, by type-casting all such inputs as char-arrays using the builtin char function. If we do this at the top of our function, then the rest of the function can remain unchanged. For example:
Readers of this website may have noticed that I have recently added an IQML section to the website’s top menu bar. IQML is a software connector that connects Matlab to DTN’s IQFeed, a financial data-feed of live and historic market data. IQFeed, like most other data-feed providers, sends its data in asynchronous messages, which need to be processed one at a time by the receiving client program (Matlab in this case). I wanted IQML to provide users with two complementary modes of operation:
- Streaming (asynchronous, non-blocking) – incoming server data is processed by internal callback functions in the background, and is made available for the user to query at any later time.
- Blocking (synchronously waiting for data) – in this case, the main Matlab processing flows waits until the data arrives, or until the specified timeout period has passed – whichever comes first.
Implementing streaming mode is relatively simple in general – all we need to do is ensure that the underlying connector object passes the incoming server messages to the relevant Matlab function for processing, and ensure that the user has some external way to access this processed data in Matlab memory (in practice making the connector object pass incoming data messages as Matlab callback events may be non-trivial, but that’s a separate matter – read here for details).
In today’s article I’ll explain how we can implement a blocking mode in Matlab. It may sound difficult but it turns out to be relatively simple.
I had several requirements/criteria for my blocked-wait implementation:
- Compatibility – It had to work on all Matlab platforms, and all Matlab releases in the past decade (which rules out using Microsoft Dot-NET objects)
- Ease-of-use – It had to work out-of-the-box, with no additional installation/configuration (which ruled out using Perl/Python objects), and had to use a simple interface function
- Timeout – It had to implement a timed-wait, and had to be able to tell whether the program proceeded due to a timeout, or because the expected event has arrived
- Performance – It had to have minimal performance overhead
Last week I showed how we can speed-up built-in Matlab functions, by creating local copies of the relevant m-files and then optimizing them for improved speed using a variety of techniques. Today I will show another example of such speed-up, this time of the Financial Toolbox’s maxdrawdown function, which is widely used to estimate the relative risk of a trading strategy or asset. One might think that such a basic indicator would be optimized for speed, but experience shows otherwise. In fact, this function turned out to be the main run-time performance hotspot for one of my clients. The vast majority of his code was optimized for speed, and he naturally assumed that the built-in Matlab functions were optimized as well, but this was not the case. Fortunately, I was able to create an equivalent version that was 30-40 times faster (!), and my client remains a loyal Matlab fan.
In today’s post I will show how I achieved this speed-up, using different methods than the ones I showed last week. A combination of these techniques can be used in a wide range of other Matlab functions. Additional speed-up techniques can be found in other performance-related posts on this website, as well in my book Accelerating MATLAB Performance.
A client recently asked me to assist with his numeric analysis function – it took 45 minutes to run, which was unacceptable (5000 runs of ~0.55 secs each). The code had to run in 10 minutes or less to be useful. It turns out that 99% of the run-time was taken up by Matlab’s built-in fitdist function (part of the Statistics Toolbox), which my client was certain is already optimized for maximal performance. He therefore assumed that to get the necessary speedup he must either switch to another programming language (C/Java/Python), and/or upgrade his computer hardware at considerable expense, since parallelization was not feasible in his specific case.
Luckily, I was there to assist and was able to quickly speed-up the code down to 7 minutes, well below the required run-time. In today’s post I will show how I did this, which is relevant for a wide variety of other similar performance issues with Matlab. Many additional speed-up techniques can be found in other performance-related posts on this website, as well in my book Accelerating MATLAB Performance.