No announcement yet.

Graphic Updates Too Slow for Car Gauges

  • Filter
  • Time
  • Show
Clear All
new posts

  • Graphic Updates Too Slow for Car Gauges

    I'm developing a car gauge, or so I thought, but the refresh rate using media_VideoFrame is much too slow to update the image realistically.

    For now, I'm just using the following code to iterate the gauge from 0 to 50 and back to 0 to see how it will work out, but it takes 6-8 seconds for the needle to sweep left-right-left... Much too slow.

    The gauge image(s) are compiled and stored on the microSD card, and I thought I could use clipping to make it faster, but nothing seems to help.

    Is there anything I can do to speed things up?

    gaugeBoost(); gfx_Clipping(1); // set clipping on gfx_ClipWindow(20, 10, 78, 108); // set clipping region var boostX; media_SetAdd(igauBoostH, igauBoostL) ; // point to the gauBoost image for (boostX:=0; boostX=0; boostX--) media_VideoFrame(0, 0, boostX) ; // where boostX is 0 to 50 (for a displayed -1 to -1) next gfx_Clipping(0); // set clipping off sleep();

  • #2

    Much too slow.
    Seems like you are getting about 13 updates per second, you wouldn't normally raise the boost 1 increment at a time, you need to focus on the 13 updates per second, not sweep times.

    Clipping will only speed things up in certain situations, and you need to turn it on after you set the window.

    If you really want faster, you will need to use a 'non pretty' gauge, have a look at the Goldelox Designer, general examples, Goldelox_Clock demo.


    • #3

      Thank you for your reply. I'll try the clipping suggestion.

      Unfortunately, because the gauge must be photo-realistic or at least very attractive, it must "sweep", and that requires movements of one unit at a time. If it were to "jump" from value to value, it would look very bad compared to the actual gauges in the car. I might be able to get away with movements of 2 units when large or fast movements are necessary - I'll see how it looks.

      While it doesn't have to update in "real time" it must be fast and responsive, and while the actual value will be smoothed with an exponential moving average it still needs to update rapidly, especially for something like boost/vacuum which are useful as diagnostic tools.

      If 13 frames per second is the maximum value, I might need to look at other products, but I'm very new at this and the 4D stuff was the first thing I came across.

      Thanks again for your help!