Sign up for our newsletter! 
Home News Products Downloads Forum Distributors Store Contact Us
PPE User Forum
December 11, 2017, 05:36:26 pm *
Welcome, Guest. Please login or register.

Login with username, password and session length
 
   Home   Help Search Login Register  
Pages: [1] 2 3  All
  Print  
Author Topic: DC Performance in Dash View  (Read 27749 times)
0 Members and 1 Guest are viewing this topic.
audisnapr
Jr. Member
**
Offline Offline

Posts: 75


View Profile
« on: July 19, 2010, 10:11:32 am »

hey guys - anyone have suggestions on making my dash refresh faster?  In the data logging view, RPMs, AFRs and other PIDs refresh incredibly fast, but in the dash view, they are noticeably slower and can get even slower over time.  Obviously the short answer is to upgrade the PC, but we are limited since we are running a netbook (size) with a solid state hard drive (vibration).

I've tried to create a very basic dash board, but maybe there is some fat to be trimmed?  Any suggestions on where to start?  Different font?  Get rid of the jpg shift and warning light - or lower their resolution?

Our dash view looks something like this:




* 4am-17.dxls (79.05 KB - downloaded 342 times.)
Logged

Weston@PPE
Administrator
Hero Member
*****
Offline Offline

Posts: 2234


View Profile
« Reply #1 on: July 19, 2010, 04:28:12 pm »

There is almost always places you can speed up a dashboard, but its not always easy to do.

The most important part of this is utilizing layers correctly. Needles and things that might need to be updated should be in the foreground layer, and background things that won't ever change can be in their own background layer. Removing opacity can also speed things up considerably (especially if you use it a lot).

After just taking a quick look you have everything in the foreground layer, which means it all has to render each frame that any OBD-II data changes (you know, just about every frame). Your maxqdata container should be completely moved to the BG, and all your text labels (like H20, Oil P, etc) should probably be moved too. Basically anything that doesn't change should be in the BG layer. If anything in the BG layer changes using an OBD-II value, it won't make any difference -- it will render like it does now. Conditions, Needles, and Text using the OBD-II value should not be in the BG layer.

My computer is rendering at ~72ms. Try moving some stuff around and let us know if it goes any faster. I can help you out with it if you need.
Logged
audisnapr
Jr. Member
**
Offline Offline

Posts: 75


View Profile
« Reply #2 on: July 20, 2010, 11:32:03 am »

thanks for the reply, Weston.  Is there a different between the "background layer" and the background dashboard?  Where should I put the static stuff, the bg layer or dashboad?
Logged

Weston@PPE
Administrator
Hero Member
*****
Offline Offline

Posts: 2234


View Profile
« Reply #3 on: July 20, 2010, 02:29:45 pm »

The background dashboard is a little different, since you only use a single dashboard you shouldn't need to worry about that.

In your dashboard there is already 2 layers, but you've only put things in the bottom layer (objects are rendered starting at the top of the list, going down -- meaning this is the foreground layer).

I've attached what I was able to do with it in about 30 minutes. At the loss of a few visual effects, I got the render speed to be between 20ms and 50ms, depending on the RPM (Longer gauge = more time to render). The old render time was 40ms to 85ms, so you should see a very definite improvement. I added a middle layer for some objects that are based on conditions and don't look like they change as much, which can help render speed just a little more.

With your note about it getting slower over time, I think you were noticing that when you have a higher RPM it takes more time to render the large hatched path you used for the needle (which is why I've listed a range of times throughout this post).

* audisnapr.dxls (72.5 KB - downloaded 336 times.)
Logged
audisnapr
Jr. Member
**
Offline Offline

Posts: 75


View Profile
« Reply #4 on: July 20, 2010, 02:53:07 pm »

wow!  I see what you've done in a few areas.  thanks for taking the time to do this!

I had been working on my own version at "work" as well.  However, I didn't create a middle layer like you've done, but I see how that can be very helpful.  The warning lights don't show up as often so they can be put down the list a bit.  My only covet is that I had liked the warning light image (jpg) to be over the text so that it would tone down the text and call attention to the warning itself - but I guess the red is pretty bold regardless.

In thinking about vectors and hatch patterns, would creating individual lines that make up a "hatch" help make the tach and dash faster?  What I mean is to create a mask, much like I have now.  The mask will create the overall shape of the tach.  Behind the mask I have the individual lines.  On top of both I have a simple rectangle box that gets pulled out of the way as the RPMs increase reveling the "hatch" I created.  So instead of the hatch moving or it being a hatch at all, I've created static lines with a box that gets moved out of the way.
Logged

Weston@PPE
Administrator
Hero Member
*****
Offline Offline

Posts: 2234


View Profile
« Reply #5 on: July 20, 2010, 03:18:54 pm »

I did notice that you wanted the text to be dulled with the red, but that also requires running the opacity calculations every frame which will slow it down. If you do really want this effect, try making a second condition in the foreground and show off-color text instead. This achieves the same thing, but keeps the number of objects rendered to a minimum.

A "quick fix" for you wanting the bars for the tach would be to put in some gray tick marks above the black rectangle that moves back and forth. I actually did almost exactly what you are suggesting by making the container clip to the path, and then render just a standard rectangle.

Here is another that dulls the text on the AFR gauge, and draws some tick marks over the rectangle. Even just this small amount of tick marks (40) adds 10ms to the render time, bringing it up to 30-60, which is almost halfway back up to where it was. Note I'm on a desktop with a dual-core 2.58GHz processor. A small, in-car PC will have much more trouble. If you are really concerned about the render speed, I would suggest just leaving it a big black rectangle. Using lines instead of tick marks won't speed it up much any either. The only thing that would speed this process up would be to actually cut these lines out of your path. This would result in a larger path, but still less rendering so its faster than a bunch of lines.

* audisnapr.dxls (82.52 KB - downloaded 325 times.)
Logged
Weston@PPE
Administrator
Hero Member
*****
Offline Offline

Posts: 2234


View Profile
« Reply #6 on: July 20, 2010, 03:27:35 pm »

I think I misunderstood your idea a little.

If you made your set of tick marks in the background, and moved a gray rectangle out of the clipping region, this would work and be much faster than actually rendering your hatch. Here is another that does it this way. This also reduces the high RPM rendering, so it lowered it from 50ms to more around 40/45ms on my desktop. Great idea!

* audisnapr.dxls (75.49 KB - downloaded 337 times.)
Logged
audisnapr
Jr. Member
**
Offline Offline

Posts: 75


View Profile
« Reply #7 on: July 20, 2010, 03:32:31 pm »

awesome!  I can't even keep up with you!

the gray shift lights, they are 100 opacity.  I changed them back to 255, but replaced the .png with a dulled out version so that the place-holder light looks the way I had wanted it to - basically not stand out.

let me check your latest creation.
Logged

Weston@PPE
Administrator
Hero Member
*****
Offline Offline

Posts: 2234


View Profile
« Reply #8 on: July 20, 2010, 03:36:24 pm »

The gray lights are in the BG layer and don't change, so they are only rendered once. Not a very big deal to have some opacity in the BG layer. If you liked the old ones better, you can change them back without a performance penalty. Your change would have helped in your first version, where they were still in the foreground, but since they have been moved it isn't a big deal.

The thing about the layers is that DashCommand will save a layer, and will just copy the last frame's render of the layer if nothing has changed. If there is anything in the layer that changes, the entire layer gets rendered again. This is why having a BG layer helps so much, and why the middle layer can help in certain situations. Having more than 3 layers is just too many, and isn't needed (2 will usually do fine).
« Last Edit: July 20, 2010, 03:38:50 pm by Weston@PPE » Logged
audisnapr
Jr. Member
**
Offline Offline

Posts: 75


View Profile
« Reply #9 on: July 20, 2010, 03:46:55 pm »

I gotcha.  Very clear.

I see that you leave out the gray rounded rectangle.  It hurts performance, doesn't it?  I guess the only way to get that back without a performance hit is to cut that into the path, correct?  I guess I could move everything up a tad so that the RPM number doesn't have to overlap the RPM gauge... hmm...  it needs some sort of separation.

btw, on my work computer, I see 16ms for the most part.  When we started this exercise I was seeing 16's to 30's and sometime 40's.  I shutter to think what they were on the car pc.

Logged

Weston@PPE
Administrator
Hero Member
*****
Offline Offline

Posts: 2234


View Profile
« Reply #10 on: July 20, 2010, 03:59:49 pm »

Yes, the opacity on that rectangle slows it down. Translucent things should be avoided whenever possible when you are hoping for a resource-friendly dashboard. I removed it trying to see just how fast I could get the dashboard. If you made it fully opaque you could put it in and wouldn't notice any difference. It really just depends on whether you want it to look good, or be fast.

Instead of taking the time to cut this into the path, I would just put the rectangle back in with 255 opacity.

It sounds like your computer is a little faster than mine, when we started I was seeing 40s up to 85s. You probably won't see anything less than 16ms since that is the processor resolution on most 32-bit processors. If your car pc is a netbook, I would guess it was seeing render times of 100ms+ easily at high RPM. I don't know any of the specs on it but that's my guess.

Let us know how everything works out. You will still need to copy that condition to make the text duller if you want, just don't do it using opacity because it is more CPU-intensive. 40ms top render time is pretty good (judging by other dashboards I've done on this computer), you should be much happier with its performance on your in car pc. The default skin that comes with DashCommand renders ~80ms on this computer for the Performance tab. Its a little lower for other tabs though.
« Last Edit: July 20, 2010, 04:04:42 pm by Weston@PPE » Logged
audisnapr
Jr. Member
**
Offline Offline

Posts: 75


View Profile
« Reply #11 on: July 20, 2010, 04:06:20 pm »

oh ok.  I thought I had already changed that rectangle to 255 opacity before I uploaded it - I have no problem with it being solid - at least the RPMs are readable.  Even as an opaque rectangle it still seems to slow things down.

Yup, I will use the condition you created - I like that look better.

Thanks for the lessons - great stuff.  We are really excited about this stuff.  Now we just need to keep the PC cool enough as to not melt after 30min on track.  We have some fans being shipped right now.

BTW, here's a vid from Saturday of Jason taking the car for a spin in the parking lot for a shake down run.

http://www.youtube.com/watch?v=OTFmeaw4NW4
Logged

Weston@PPE
Administrator
Hero Member
*****
Offline Offline

Posts: 2234


View Profile
« Reply #12 on: July 20, 2010, 04:19:50 pm »

It looks like you did change it to 255. I guess I was assuming it was still translucent like in your first screenshot. I can't really see much of a difference in render speed, judging by the numbers up top maybe 1 or 2ms tops. I don't have the same fonts or screen resolution as your car pc, so without that rectangle the numbers don't overlap on my computer. Its easy to forget how much a dashboard can change depending on the resolution.

The car looks great. We'd love to see a video of how DashCommand looks while its running (you don't need to be moving).  Grin
« Last Edit: July 20, 2010, 04:22:25 pm by Weston@PPE » Logged
audisnapr
Jr. Member
**
Offline Offline

Posts: 75


View Profile
« Reply #13 on: July 20, 2010, 04:30:33 pm »

We'd love to see a video of how DashCommand looks while its running (you don't need to be moving).  Grin

that can be arranged  Wink
Logged

audisnapr
Jr. Member
**
Offline Offline

Posts: 75


View Profile
« Reply #14 on: July 20, 2010, 06:30:33 pm »

reporting back  - on the pc we are using in the car and with the warning lights (middle layer) turned off, I'm seeing 32-47ms throughout the RPM range - this includes the shift lights.  Once all 4 warning lights turn on, I see 60-80ms with an occasional 47ms

<edit>
forgot to mention that I did test the original file too: 120-140+ ms  Cry
« Last Edit: July 21, 2010, 08:40:45 am by audisnapr » Logged

Pages: [1] 2 3  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.13 | SMF © 2006-2011, Simple Machines LLC Valid XHTML 1.0! Valid CSS!
Page created in 0.067 seconds with 20 queries.
Home | News | Products | Downloads | Forum | Distributors | Store | Contact Us
Copyright © 2013 Palmer Performance Engineering, Inc. All Rights Reserved.