Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD General Discussion
T0rin
Beginner


Joined: 27 Dec 2008
Posts: 14

PostPosted: Fri Apr 08, 2011 11:53 pm   

Trying to optimize UI with lots of buttons/images
 
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.


Last edited by T0rin on Sat Apr 09, 2011 12:09 am; edited 2 times in total
Reply with quote
T0rin
Beginner


Joined: 27 Dec 2008
Posts: 14

PostPosted: Fri Apr 08, 2011 11:59 pm   
 
Here is some of the code used on the buttons..

First button below the purple gauge:
Code:
%if(@fighting=1,%if(@flipping=1,"flipping","fighting"),%if(@standing=1,%if(@flipping=1,"delayed","standing"),"sitting"))


Button below that:
Code:
%if(@haveweapon=1,"have weapon","missing weapon")


An example image button:
Code:
%if(%len(%btnimage(elarbutton1))>0,%eval("@"%copy(%btnimage(elarbutton1),%eval(%pos("s\",%btnimage(elarbutton1))+2)
,%eval(%pos(".",%btnimage(elarbutton1))-(%pos("s\",%btnimage(elarbutton1))+2)))"time"),"")


The last bit basically extracts "sanctuary" from "mud\icons\sanctuary.bmp" and then the value of the caption becomes "@sanctuary". (and thus the value of @sanctuary)
Reply with quote
Shezmu
Wanderer


Joined: 23 Apr 2010
Posts: 53

PostPosted: Sat Apr 09, 2011 12:37 am   
 
T0rin, I envy your uber-UI ness. Good looking screen.
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Sat Apr 09, 2011 12:56 am   
 
Quote:

I'm wondering what exactly is to blame.


The simple fact you have 51 buttons on-screen that employ variable-based information. Any time at least one variable referenced by a button changes, it causes a windows repaint. Since all 51 buttons seem to be interrelated or at least operating on the same groups of information, that's 51 screen repaints moreorless on every line received.

One thing you might be able to do is to swap the buttons for text. Even though you lose a bunch of the "automatic" aspect, text is always a lot faster than buttons.
_________________
EDIT: I didn't like my old signature
Reply with quote
T0rin
Beginner


Joined: 27 Dec 2008
Posts: 14

PostPosted: Sat Apr 09, 2011 1:56 am   
 
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.
Reply with quote
Moo
Apprentice


Joined: 10 Apr 2009
Posts: 145

PostPosted: Sun Apr 10, 2011 11:58 am   
 
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.
Reply with quote
T0rin
Beginner


Joined: 27 Dec 2008
Posts: 14

PostPosted: Sun Apr 10, 2011 1:51 pm   
 
Moo wrote:
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.


An interesting thing about that... the MUD I usually play on allows 3 characters at once, and 1 weekend every 2 months you're allowed 5 character. This weekend is that weekend, and yesterday I had 2 characters not tied to my UI (with all the gauges/buttons/everything) and the 3 that were, were sitting still in a room. I speedwalked the other 2 characters who were completely unrelated to the UI, and still CMUD was lagging hard. I closed the session with the UI, and re-ran the speedwalk with the other 2 characters and everything was fine. So, it seems to be unrelated to updating the gauges and other variables tied into the UI, but rather massive feedback from the MUD (like you get when you speedwalk) in combination with simply having that session open, causes the lag.


Last edited by T0rin on Sun Apr 10, 2011 7:27 pm; edited 1 time in total
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Sun Apr 10, 2011 5:20 pm   
 
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.
_________________
EDIT: I didn't like my old signature
Reply with quote
T0rin
Beginner


Joined: 27 Dec 2008
Posts: 14

PostPosted: Sun Apr 10, 2011 7:34 pm   
 
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..
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Sun Apr 10, 2011 9:42 pm   
 
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."
_________________
EDIT: I didn't like my old signature
Reply with quote
Derar
Novice


Joined: 09 Sep 2006
Posts: 44

PostPosted: Tue Apr 12, 2011 12:53 am   
 
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).
Reply with quote
GeneralStonewall
Magician


Joined: 02 Feb 2004
Posts: 364
Location: USA

PostPosted: Thu Apr 21, 2011 2:59 am   
 
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
Code:
#loopdb @auto_scans {
  #CALL %btncol( {btn_%key}, white, darkgreen)
  }
#sendraw {i_onall}


Even though this is an alias that I tend not to use very often, there's obviously some extreme performance issue going on with it.

The rest of the buttons are just caption displays such as, '"Left Arm": %db(@hit_counter, "left arm")' and 'Paralysed: %ismember(@enemy_affs, paralysis)'. As a whole, these cause a noticeable drag on Cmud as the variables they reference are updated.

As I recall, I was told this was partially Windows 7 fault for whatever reason; but it seems 'some other mud clients' pull off custom displays like this quite well without the performance cost. It's really one of the bigger downsides of Cmud for me at the moment and has lead me to experiment with other clients. While I find Cmud to have the best interface, scripting capabilities, and overall reliability, I'm finding myself willing to sacrifice some of those things for better performance. Obviously these feelings are my own, but I do believe this is an issue that warrants some attention. (Though I realize Zugg can't magically create time to do everything and I appreciate all the hard work he's put into creating what I know is the best overall mud client out there.)
Reply with quote
T0rin
Beginner


Joined: 27 Dec 2008
Posts: 14

PostPosted: Sat May 07, 2011 1:03 am   
 
It isn't just Windows 7, running the same settings on XP and Vista produce the same results as well.
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Sat May 07, 2011 2:35 am   
 
Windows 7 is Vista plus bugfixes. For the purposes of this thread, they're the same OS.
_________________
EDIT: I didn't like my old signature
Reply with quote
Sutex-Kindred
Apprentice


Joined: 26 Aug 2009
Posts: 141

PostPosted: Mon May 09, 2011 8:57 am   
 
That looks good , can you Please post the finished script of you UI so we can have a mud cockpit like yours !
_________________
Entropy rules
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD General Discussion All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net