Reset button

[Weston@PPE]

When a layer has something change that requires an redraw, every layer lower than it in the list also has to redraw (because if there is any alpha bending, it needs to be re-blended against the new background). Individual layers that are not at the very bottom (foreground) of the layer list can not be redrawn on their own.

I haven't looked at the design of your dashboard in the editor, but using extra layers does still increase render time even if they aren't changing, especially on newer high resolution devices. Tuxedo used to have 3 or 4 layers per page, and when the iPad 3 with Retina came it the cache for each layer was so large that the framerates dropped to the point of being unusable. Since then we've reworked Tuxedo to use only 2 layers on as many dashboards as possible, only a few dashboards still use more than 2. We also moved the menu into each dashboard so we could remove the foreground/background dashboards, which removed 2-4 more layers.

It still has to draw a whole screen cache for each layer to the screen, even if it isn't rendering new content to the cache first. In the case of a Retina iPad, thats 3.1 million pixels per layer that is not avoidable.

[Nak]

Thanks for the info Weston!

Hey, I have a couple of questions about speed. When you have different objects in the back ground activated by changing states, say multiple gauge backgrounds in the same spot selected by button press, does that slow down the dash? Also, the needles for those gauges in the foreground: when the gauge isn't active because of state, is it still using that PID and slowing it down that way? In other words, say I cycle through 5 different gauges by cycling state, Is it as slow as a dash with all of those gauges visible, is it as fast as a dash with just the one gauge since that is what is active, or is it somewhere in between?

Thanks!

[Weston@PPE]

An object that is hidden, by a state tracker or other means, is skipped when we are checking for changes. A state tracker in the background will only slow down on the one frame when it changes, and after that we will know that the layer hasn't changed since its previous render.

If you have 5 gauges in the foreground and 4 are hidden, the entire layer still gets re-rendered if that one gauge changes. If the rendered objects are actually hidden completely they won't be rendered which will speed things up, but just disabling the needle and leaving things visible won't help much.

If a needle is hidden it is also skipped when we search for the PID list. However, you will need to check the box "Refresh PID List" on your DashXL objects that hide/unhide needles in order for this change to take effect. We do not routinely scan and update the PID list, its done one time on the first render and then only when a DashXL object requests it after that.

[Nak]

Great info! Thanks! That really clears a bunch up for me. One last thing: Can you cycle a state via a condition? I know how to do it with a button, but can it be done with a condition? I was thinking putting a button set up under a condition, but with no object that would define the button press area. Instead, each condition--true and false--would set the "depressed" or "not depressed" state. Would this work?

Thanks!

[Weston@PPE]

Conditions are based off of PID data, there would be no way to get the depressed/not depressed data into the condition. You could use a condition to display different buttons at different times though. If there is no object defining the not depressed touchable area of a button, it is impossible to click that button. The touchable area can be an object with no pen and no fill however, to make it invisible.

[Nak]

I get that the condition is set by a PID. What I'd like to do is set a state if the condition is true, and set a different state if the condition is false. My question was not so clear!    Anyways, is this possible?

Thanks!!

[Weston@PPE]

Thats essentially what a condition does, it is its own state tracker and sets the true or false containers inside depending on the condition. It is not possible to set an external state tracker based on a condition, you'll need to re-create the condition in every place you want to use it.

[Nak]

OK, Got it. What I'm trying to do is put warning lights in the background so they don't slow up the dash once they light up. Will it slow down the dash much if I put a condition in the background? The condition would only change rarely, but there would be a condition tracking a PID in the background.

[Weston@PPE]

If your background is a solid color, you can easily put the lights in the lit up state in the background, and then cover them with conditions that are in the foreground with a simple solid color ellipse. This is much much faster to draw a single solid object per light than drawing a complicated light each frame. I've done this numerous times.

I also like to do a similar thing with my buttons to keep them responsive, I'll draw the button itself in the background and use an invisible rect in the foreground for the state tracker. The depressed state of the state tracker will draw the down state of the button momentarily but it keeps a lot of objects in the background this way. I do this for the Tuxedo navigation buttons if you'd like an example.

[Nak]

Thanks Weston!! I'll work on that setup. The issue is my warning light is the face of the gauge itself, so I have to redraw the gauge background--tickmarks and such. If I put the warning light in the background then the redraw would only happen when the warning symptom changed. But then I'm tracking a PID in the background. The condition would only change in the case of an overheat or under voltage, so hopefully never, but at most once anyways.

I already stole your button design for my buttons! It works great!

Thanks!

[Weston@PPE]

In that case it'd probably be the fastest to just draw your light in the foreground only when the condition is set. I did that on a custom user's dashboard here:
http://www.dashxl.net/dashboard.php?dashboard=382

You can play with the needle tester on that dashboard and see how slow it makes everything go, but that is what the user wanted. Doing it this way makes it so nothing is drawn when the light is off, but it is drawn when the light is on. Putting it in the background will make it very very slow anytime the light changes, which would make it a worse position if the light ever changes on/off with any kind of speed at all.

I did do the solid ellipse method for the staging lights on the Performance page. You have to push the Start button to see them, but they are all drawn in the background and then covered up when I don't want them.

[Nak]

I'm not worried about the dash slowing when the light changes, I just don't want it slow when the light is either on or off. If I put a condition in the background layer, it changes my redraw times from 7 - 8 ms to 60 -70 ms--even when the light isn't changing. My assumption was that if I'm monitoring a PID in the background layer--even if nothing changes-- the background must start redrawing every frame. If it's really only going to slow it down when the light actually changes if I put it in the background, then that's a different story. For instance, If I put in a low fuel warning at 4 gallons, the condition will activate once at four gallons and stay there. The light won't go out until I refill the tank. I'd like to put a yellow hatched background behind the tickmarks and arcs, but then I'd be drawing the yellow hatch pattern, the tickmarks, the arcs, etc, every frame. If i put it in the background that would be great, as long as it only redraws the background once. But it seems to be redrawing the background every frame, at least that's what it looks like from my redraw times in the upper left corner. I haven't actually tried it live.

Here's my dash with an example Low Fuel warning. It's in the background under the "Fuel & DTE" container.

[Weston@PPE]

The needle tester is not a complete replacement for the real PID system in the software. There are many cases where the needle tester will force a redraw that the software itself would not. The Tuxedo dashboard uses conditions in the background to control tick marks based on the user's unit & format settings, it only slows down for the frame when the condition changes.

[Nak]

Thanks! You're right, I ran that dash live and it works fine.

[bosseric]

You can reset the entire trip. Look at any dashboard that has a reset feature. Here's my current dashboard. Tapping "A MPG" resets the trip that is associated with. Tapping the trip odometer resets that trip. khac dau ten