Algodoo

This is probably the best looking UI in Algobox, however i can't help but remark the usual problem here: This scene takes up about 45% of the step calculation time (took the value from the profiler [the "minus" key]) mainly because there's a lot of code on many objects' postStep. I found using only one object with postStep code to be much more forgiving in terms of sim time cost (or even better, no poststep code at all, or make it appear on click then delete it after you're done using it), and then you could use entityByID (or entityByGeomID) to refer to e.g. the four boxes from the sides of the buttons (by previously saving the entityID or geomID on a scene.my var, by using onSpawn so that the code only runs when the id changes).

The rifle with aim scene uses this technique (it needs one scene.my. variable per "muscle" axle) but has close to zero simulation time overhead when on idle.

Thanks for the evaluation and suggestions. I plan on dissecting the scene and see what is causing the lag. My first guess was that it was the multitude of scene.my object variables since an object variable is created for each form and control upon spawning. I'm not sure if I agree with the statement "This scene takes up about 45% of the step calculation time ... mainly because there's a lot of code on many objects' postStep." When I check the basic (12) controls on the left of the scene, (7) have no post step code, (3) check to see if the control has focus before running postStep, (1) ("Display1") only has (5) lines of code in postStep, and (1) checks the mouse pos before running postStep (Toggle1"). I like your idea of creating postStep on demand.

After checking out the percentage draw from each example and each control, I can see that the option box and the toggle button are the heavy hitters. I will need to focus on those first. I also just realized I can reduce the percentage draw 60% by running the scene at 60 Hz instead of 300 Hz.

Well, I just realized that you used scene.my's to store entityID's, nice

Honestly this is not exactly proven, but by experience I found out that having many scene.my variables doesn't really make any lag. The problem is reading and/or writing to them on every step, so for example if we have a box and we want to change its collideSet, doing
collideSet = {scene.my.collideSet}
or doing that from postStep as in
postStep = (e)=>{collideSet = scene.my.collideSet}
will read it every step, which is a small overhead on itself. Also writing with a laser, like we did 5 years ago, writes it every step, so it's basically code running unnecessarily. all of these end up piling up and they use up a rather big amount of step time.

I believe the first step in making the buttons less laggy would be improving the 3d effect boxes. right now all 4 of them per button are executing code on every step. I think the simplest way would be by using a texture, and you could probably just rotate it. Otherwise you can store each box's entityID in a scene.my.var via onSpawn and have no other code running, then change each box's color from the button itself, using scene.entityByID.

Do you avoid onClick code for some reason? I saw that in the Submit button, you check for the mouse being upon the button and for a click. is there any reason other than to change _isDown?

I think you could do this in a much simpler way. Just use something on the lines of this:

onClick = (e)=>{
scene.my.focusID = entityID;
_isDown = true;
postStep = (e)=>{
! Keys.isDown("mouse_left") ? {
_isDown = false;
postStep = (e)=>{}
} : {}
};
_onClick
}

also, one more thign about the sliders. you might have noticed that they will not stay attached to the cursor if you exit their area (i.e. move the cursor too fast to the sides or up). I think a good way of solving this would be saving the initial distance in the X axis between the center of the slider box and the mouse pos, then simply using the mouse position in the X axis minus the x distance (with the desired limits) as the slider pos while the left mouse button is pressed. this way you don't have to rely on the mouse staying inside of the slider box area

S = Statement, R = Response

S: Well, I just realized that you used scene.my's to store entityID's.
R: I use scene.my.focusID to store the entityID of the active control. I use scene.my.[control _name] as object variables to store each control so that I can call each control by name at any time. I use _parentID in parts of each control that are not the main control box.

S: Honestly ... they use up a rather big amount of step time.
R: I concur.

S: I think the simplest way would be by using a texture, and you could probably just rotate it.
R: My first thought was to use a texture, but I never thought about rotating it. My concern is that if I double the size of a button in one dimension, then the border for the wider dimension will be twice as thick. If using a texture improved the control perfomance by more than 25%, then I may ingnore that issue in favor of performance.

S: Otherwise you can store each box's entityID in a scene.my.var via onSpawn and have no other code running ...
R: Good idea exept that I would try to use local _variables to to store EntityIDs.

S: ... then change each box's color from the button itself, using scene.entityByID.
R: That makes sense; use (1) postStep instead of (4).

S: Do you avoid onClick code for some reason?
R: I would use onClick but onClick code appears to execute on mouseUp, not mouseDown.

S: Just use something on the lines of this: ...
R: Another good idea that I didn't think of. I will try that.

S: ... sliders. you might have noticed that they will not stay attached to the cursor.
R: I did notice that.

S: I think a good way of solving this ...
R: I agree. I will try that.

P.S. I tried the suggested code and some variations, but could not get it to work. The scrollBar suggestion worked out well. I chose to leave the command button border control code in the borders because I didn't want to add more member variables to the button's main box. I did add a scene.my.GUIstrobe codition to the border postStep, so they should be runnining a 10% sim frequency.

P.P.S. I changed the Button1 code so it clicks even without having focus. This will cause a performance hit, but I'm not sure how to improve it.

Problem: My concern is that if I double the size of a button in one dimension, then the border for the wider dimension will be twice as thick

Theoretical Solution:
Make texture with borders that are 1 pixel wide and use texture clamped [true,true]
So when you want to have 2 times longer button just make texture 2.1 times so you "shrink" verticall borders and it will look same
MAIN PROBLEM: I didn't played this scene yet, I have too much work to do, so this is the only way i can still be part of algodoo

Stated Problem: My concern is that if I double the size of a button in one dimension, then the border for the wider dimension will be twice as thick.

Solution: Change the size of the buttons, save the buttons in scene, and then reload the scene. The button borders will all be the same size.

P.S.: Thanks for the suggestion. I may be able to use it elsewhere. I probably should have mentioned that the buttons re-scale on re-load. There may be other functions of the controls that only work upon re-loading. So if the controls don't work as expected, then try reloading the scene.