Unless I'm mistaken, each call to SetAttrs() can cause that object's window to be refreshed. If there's an extensive sequence of such calls, could I turn off that behaviour until the sequence is completed? Or would the efficiency gain be too small to be noticed on 1GHz+ systems?

Quote:

If you set an attribute the object will only be redrawn if needed and the number of those attributes are quite limited. e.g. if you set MUIA_Numeric_Max or Min you won´t see any action unless the currenty shown number gets out of bounds. Also if you set an attribute to an identicall value nothing will happen at all.

The window only gets redrawn if you change gadgets contents and it no longer fits into its prior size. e.g. changing the contents of a cycle gadget. In that case mui tries to fit the gadget into the window by using any space possible, but it could be that the window needs resizing. You can do this by using a virtual group, which adds sliders in such case. This is what e.g. the preferences and screenbar settings panels are doing. If there is not enough space, they become scrollable to avoid window resizing. Just remember the window could be at screen size before and then you are doomed. Relayout will fail and mui will close the window with an layout error. So always make sure this never happens.


The only exclude from this is the list, which you can set to quiet before extensive adding/removing/changing list entries. This not only avoids gigantic flickerung, but also speeds up things alot.

So just don´t care about it and do the change.

If you have 80 text fields you want to change, then this could be a problem regarding flickering. In that case I would put them into a group and simply set MUIA_ShowMe, FALSE until all gadgets inside are updated and perform the same with TRUE at the end. However this may look even worst in such case.

Another way for such case would be to create a page group. Page 1 with all the text fields and page 2 with some centered "processing data" gadget. Now you can simply flip page, update and flip back. Even if the processing data stuff is only visible for a facture of a second it is better than having all gadgets flickering.

However. Best is to check how it looks by default and afterwards try the work around that fits best. Usually it is not required since there are far less objects to deal with. MUI allows easy adding such behaviour later on. No need to invent something useless and complicated in the first place.

[ Edited by geit 10.02.2017 - 23:46 ]

My project has a little over 200 non-static text objects. Not all of them always need to be updated after every user input but sometimes that will be the case. imad0f8fb.jpg

[ Edited by ausPPC 11.02.2017 - 11:28 ]

You could try to set MUIA_Window_Sleep to TRUE, don't know really if it helps but its worth a try;)

InitChange/ExitChange on the window's root group should do the trick.

Thank you for the suggestions. I tried the Group_InitChange / Group_ExitChange methods but updating Text_Contents between those calls still changes the display before Group_ExitChange (I used a call to Delay() after the update but before Group_ExitChange so I'd be able check this behaviour).

You might want to try a non notify set maybe coupled with init/exitchange.

If performance is an issue (ie refresh flickering), you could implement your own text object which would have a lot less overhead than the MUI text rendering engine.

Nice idea, Tcheko. But that sounds rather ambitious for me. I haven't noticed any flickering so far but I'm still a ways off implementing a feature that will allow the debugger to automatically step through each instuction contained in the program. I want the speed of this 'stepping' to be dialable between as-fast-as-possible and more easily observed speeds.