Report A tale of two ui update methods in LabVIEW General Posted March 27 On 3/25/2020 at 8:48 AM, Neil Pate said: Joking aside, if I am updating that many controls that the GUI is slow to paint it is probably symptomatic of a bad GUI design. Well that or some really complicated stuff is happening. Here is a UI I've been working on lately. It is the view of a sequence that is currently running. On the left is a green arrow that moves to whatever step is currently being executed. Next to this is Goto arrows showing that a step has a condition that might jump to another step. Then there is the tree control that shows the sequence. In it is the step name (I blocked out many) then two columns that show some settings on the step with icons, and a column for a comment on the step. To the right is detailed information about the step that is currently selected. I'm welcome to have some feedback but here is how I made it. The green arrow is in a pane by itself. The arrow is 2D picture control constant, and the position of the control is changed but the value of the control never changes. The set of Goto arrows is another 2D picture control. This time it takes up the whole pane and is redrawn as needed. Since the user can scroll the tree, this means we need to poll the scroll position (on mouse down, mouse move, wheel scroll, limit to 1 event) and if it changed redraw the arrows. The While Loop can be collapsed and if that happens, the green arrow needs to point to it since the current step is in the loop. In this example if the while loop is collapsed, then the Goto arrows need to be removed. This is done by reducing that pane size to 0, making more room for the sequence tree. The tree is set to fill the next pane. The icons in the tree are two separate 2D picture controls (since icons can't be in multiple columns easily, and their size is 16x16). The position and value of them are dependent on the scroll positions of the tree. To reduce weird UI stuff when resizing, the 2D pictures must be aligned to be at the top of the tree control. The 2D pictures aren't transparent because doing so means the Erase First option must be set, which ends up flickering when scrolling since these need to be changed on scroll, window resize, or collapsing of the while loop. Because of not being able to be transparent, and wanting to align to the top, the 2D pictures actually contain the headers as part of their pictures. Maybe I could have done this with another pane. When scrolling too far right or left we want only partial column icons to be drawn so the column width is checked on scroll to ensure it looks right. Also since the pictures aren't transparent, the blue background of an icon is separate image. Oh and the scroll wheel works, and will mess with lots of these things. This mostly works well. But as you might guess it can take some time to draw all these things, figure out where they should go, and get it looking right. At first I had the quick and dirty of on any Mouse Move, Mouse Down, or Wheel Scroll event, just redraw everything. This meant tons of events firing all the time doing mostly nothing, and some times flickering the screen. So then I started looking at ways to improve it. If there is a value change on the tree, we don't need to update the Goto arrows at all, just the icons. Other information can be cached too to help with performance. Maybe we could draw all Goto arrow permutations on start, and then switch between them as needed then we wouldn't have to draw them. We would only need to move them vertically as needed. This is the kinda thing I was talking about when I said diminishing returns. Right now drawing that goto arrow is probably 10ms or so. But by complicating the code we could bring it down to 1ms. Is it necessary? Well no but if the total time of doing things adds up to be too much we could look into that to reduce the performance. Oh and to add to the complicated nature of this, this is the same UI that is used to create the sequence, with dragging and dropping and moving steps around, dragging Goto arrows around, and clicking icons to perform other actions like sliding in another subpanel, or changing the icons. In all of this, the defer panel updates is only used once, and it is on a full refresh which only happens on first load. Everything else we just update what we need and it has been pretty responsive.