Zugg Software :: View topic - Trying to optimize UI with lots of buttons/images

Beginner Joined: 27 Dec 2008 Posts: 14

Here is a screenshot of my UI as it exists today: http://img641.imageshack.us/img641/1306/cmud4811.png

Prior to adding all of the gauges and buttons and whatnot on the left (everything that isn't a gauge is a separator, except the images which oddly have to be push/toggle/etc. before they will show the image, separator only show the image on mouseover..), CMUD ran smoothly.

The main issue I find is that when I speedwalk (let's say 30 directions), the MUD is, I assume, sending so many updates to the gauges (which pull information using the //class/variable format to get the hp/mana/move values from other sessions) that the client just gets bogged down. It is to the point that while speedwalking I can't even type anything into the prompt, and its not until the gauges "catch up" (2-5 seconds after a speedwalk ends and I arrive at my destination) will the prompt even accept any inputs. If I do type while speedwalking, once the client catches up it will process what I typed, but I typically tend to buffer command to send immediately when I land at my destination, and find myself having to sit and twiddle my thumbs as CMUD plays catch up.

If I disable the classes that hold the UI elements, character by character, I notice this slowdown fading away, until I disable the last class and I can type normally during a speedwalk. I had the same amount of gauges prior to revamping my UI, and had no slowdown issues, but once I added the buttons with images, it seems to have become "too much" for CMUD to handle during speedwalks.

For each image button (I have 3 rows of 4 buttons that are all typically disabled, and only enabled when an "affect icon" needs to be placed on them) I have a long %eval statement that is used to determine whether or not a value needs to be displayed, depending on whether an image is assigned to the button... so when I do want to display an affect for a character, I have an alias that finds the first "available" button, and sets an image on it. Then the %eval on the button caption kicks in, figures out what icon is being used and then displays the value of a variable based on the icon. So if the "sanctuary" icon is on, it then looks at the @sanctuary variable to determine the caption to display, that way I can display an icon with a duration next to it.

Anyways, the icon buttons WORK fine, except they lag CMUD to no end, to the point that it can't really keep up. I'm wondering what exactly is to blame. The %eval statement, the buttons with images, the gauges, a combination of all of the above? I'm wondering what I can do to optimize it... Even with all but lets say 3 of the possibly 36 "image buttons" disabled, I'll get the lag, and it just becomes worse the more I enable.

Beginner Joined: 27 Dec 2008 Posts: 14

Here is some of the code used on the buttons..

First button below the purple gauge:

Wanderer Joined: 23 Apr 2010 Posts: 53

T0rin, I envy your uber-UI ness. Good looking screen.

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Beginner Joined: 27 Dec 2008 Posts: 14

Well, the only buttons that change while speedwalking would be the move gauge, and even if I disable or even delete it, doesn't really change anything.

Also, 27 of the 36 "image buttons" are disabled most of the time, sometimes more, and still the lag.

Are disabled buttons repainted? I know that the caption isn't refreshed on its own, even if everything is painted, so those elaborate checks wouldn't be running all the time, I have to specifically #update each button if I want the caption to reflect the current value of the variable that it is "tied to".

Prior to adding these "image buttons", I had 9 gauges (vs the 14 I have now) and 12 multi-state buttons and never ran into anything like this. I do think it has something to do with the images, although if I disable all of the image buttons, I still get the lag. Truth be told, I'm just shooting in the dark, but _something_ is definitely being over-calculated/processed to the point that it can bog CMUD down to this extent.

An example of CMUD having to play catch-up... after I execute a speedwalk, I can see for the 2-5 seconds of "catch-up time" that the gauges start and tick down the move counters after the speed walk is done, as opposed to during it. It is like whatever is bogging things down is preventing even the gauges from updating mid-speedwalk, and only until after the speedwalk spam is done, will it process those updates.

Apprentice Joined: 10 Apr 2009 Posts: 145

How about.. Instead of the gauges etc being tied to the "real" variables, have them use a separate set of variables which you copy the real values into. Then you could turn off the "copy" before speedwalking and back on again after.

Beginner Joined: 27 Dec 2008 Posts: 14

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

This probably means you have far too many triggers active all at once. Examine your entire system, with the focus being on turning stuff on/off at the appropriate times. Any time a line is received, every active trigger that is not a wait-state or alarm is checked against it and how fast your triggers fail depends on the complexity of the patterns (beyond that, it's just simply mere time to get through a really big list of triggers-to-check.)

If you can't shrink this list down and fix the issue this way, you are looking at at least a moderate rewrite that changes some settings to other types (ie, aliases into functions or events) or takes advantage of user-created threading.

Beginner Joined: 27 Dec 2008 Posts: 14

Well, if the triggers are to blame, then why does all the lag go away when I disable the classes that contain the UI elements? All of the triggers are still firing..

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Because anything to do with what you see onscreen is kept in the main thread. Depending on your exact scripts, your triggers etc are also operating there and the two combined are overloading your process capacity.

It kinda boils down to what I said in my first post: "The simple fact you have 51 buttons on-screen that employ variable-based information."

Novice Joined: 09 Sep 2006 Posts: 44

Actually, I think the main problem here is that your button captions appear to be function calls.

I also run a lot of buttons & gauges, and I had a number of them with their captions tied to function calls - in particular a 10-12 item menu button had each item's caption set through a user-defined function, and I used to have a lot of the same performance hiccups that you do (though much more sporadic).

When I checked the debugger and noticed that my custom menu item function kept firing in batches of 10 alllll the time, I decided to change it. All the captions are now stored in a single list variable and each menu item's caption is @CaptionVar.1, @CaptionVar.2 and so on depending on position. The variable is updated when needed by whatever actions/events in the mud update the captions. My speed hiccups have since disappeared.

CMud buttons with Variable captions should only update when the Variable changes. With an actual variable, even a list or database, this is relatively easy to detect. But with a % or @ function, it's not really practical to determine when one component of that might or might not change, so it needs to check it all the time - and that means running the function again. It's compounded by %eval being a runtime function (if I'm not mistaken), so you're not even getting the benefit of it being compiled ahead of time. If you take all your current captions out and place them into user-defined functions, then set the captions to the new user functions, you will probably notice they're getting called like mad if you turn on the debugger.

To fix this, I'd recommend setting up scripts to manually update the buttons as needed whenever things change, and where applicable limit text caption values to actual Variables, that again, are updated at the time of the change (even if that change is just parsing your prompt each time). You can get away with function-dynamic button info when you're only running a couple, but with as many as you have, it's just not going to be pretty (as you've seen).

Magician Joined: 02 Feb 2004 Posts: 364 Location: USA

This probably could have gone in a new thread, but...

I'm have to agree with the general issue in the OP's post: Buttons are slow as molasses... At least on Windows 7, even with Aero disabled.

Take the following settings:

http://pastebin.com/CHC5TQMi

The following alias takes several seconds to execute on my computer and locks cmud in the process:

i_onall

Beginner Joined: 27 Dec 2008 Posts: 14

It isn't just Windows 7, running the same settings on XP and Vista produce the same results as well.

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Windows 7 is Vista plus bugfixes. For the purposes of this thread, they're the same OS.

Apprentice Joined: 26 Aug 2009 Posts: 141

That looks good , can you Please post the finished script of you UI so we can have a mud cockpit like yours !