Best Practices - Improving Screen Graphics Performance

Overview

The graphics part (screen) of the PowerView displays has a single loop that continually runs to keep the graphics and displayed data updated. The main screen update loop is set to run at 15 Hz (15 times per second). This is the ideal that the timer controlling the loop is set to, so in actual practice the loop will be about 13 or 14 times per second and will drop as graphics load (widgets, gauges, images) increases.

Loop Sequence

Each pass of the loop consists of these steps:

1. Process any actions that have been received from the CCM (state machines).

2. Process any screen API messages that have been received (from custom application or script).

3. Check for data refresh (data refresh is set to occur at 5 times per second within the loop)

   1. Check for updated settings (day / night mode, language, unit group, etc).

   2. Refresh data in all gauge objects from the parameter database.

4. Draw visible screen objects to screen.

Layers

The “Page Designer” environment is split into 5 distinct layers. Each layer is drawn in the update loop from bottom first to top last (Main -> Settings -> Menu -> Popup -> Overlay).

Best Practices

• Develop with CPU usage visible
  
  • The variable name is Cpu.Usage
  • You can remove the variable when you’re ready to release
  • Put the variable on every screen that has gauges while you’re doing development
  • There’s a similar variable for memory usage – Cpu.FreeMemory. We’ve seen fewer issues with configs running out of memory than we have with configs running out of CPU time.
• Use as few layers as possible
  • If the design can all be done in the Main Layer efficiently, then only use the Main Layer
  • If other layers are needed, try to keep most of the design on the Main Layer
  • Use upper level layers for objects that are only shown occasionally and are hidden again, for example: menus, softkeys, diagnostic message, etc.
  • Park all other unused layers into a blank page with the “Show In View” option set to False, this will cause these layers to be skipped in the drawing loop
• Keep the Main Layer with the “Texture View” option enabled
  • All widgets (Image and Text) that don’t change often should be in the Main Layer with property “Dynamic” set to False. Examples: background images, labels, artwork, customer labels, etc.
  • If a widget does change (show and hide) frequently due to Show / Hide commands in a state machine, scripting, or lamped, make sure that it has the property “Dynamic” set to True.
    • Remember: When a “static” object changes, all the static objects must be redrawn and saved to the static buffer that is kept on the side. This is expensive and will slow a unit down if done repeatedly and quickly.

• Reduce the number of “dynamic” objects
  
  • The number of and size of dynamic Image Widgets (images that are drawn each frame) has the most drastic impact on performance
  • Lots of dynamic text (text gauges and dynamic text widgets) will also impact performance

• Does smoothing a gauge affect screen performance?
  
  • Smoothing does not, the computation is the same regardless of smoothing value. The only smoothing that will “theoretically” affect performance due to the level used is the “Number of Samples” option on a Text Gauge since this field actually sets up an averaging buffer in that Text Gauge for the number of samples specified.
• Is it better to clear the area behind and in front of a video widget even if the video overrides the other objects already?
  • It is better to not have objects behind or in front of the video only for the reason of reducing overall object count for the system and wasting unnecessary draw cycles for those objects since Video will always cover them. Video itself isn’t affected by extra objects in front or behind it. Video is always on top.
• What happens when screen objects go beyond the viewable area?
  • These objects are still drawn and respond (show, hide, api, etc) like other screen objects, however, since they are off the screen you just can’t see them.
• Is it better to use lower bit images?
  • No, all images are kept internally as 32-bit RGBA PNGs. However, it is a good idea to remember that we are using a 16-bit color display and dithering images to the optimal bit depths for each channel can reduce the banding visible in “pretty” images that include gradients and shading. See these posts for the optimal way to dither images using Photoshop. PowerView displays use a RGB 565 color palette, so you would use the 5-bit for red, 6-bit for green, and 5-bit for blue. The first post has the needed color palettes; the second has instructions for dithering the actual image.
    • http://notlost.blogspot.com/2008/05/simulating-lcd-bit-depths-with.html
    • http://notlost.blogspot.com/2008/08/dithering-for-low-bit-depth-lcds-with.html
• Is it better to use images without transparency?
  • No difference in the system.
• Is it better to colorize images inside the configuration tool or import them in different colors.
  • No difference in the system.
• How do overlapping images affect the system?
  • There is no difference to the drawing engine, however, the images will both be drawn as whole images in their respective Z order, so the rule that more and more images drawn reduces overall performance will apply here.
• Reusing images versus using a duplicate image?
  • Always reuse images where possible. Images are only kept once in memory, so if you can reuse it rather than copy it you greatly reduce the system memory usage. If there are so many unique images that they cannot all be loaded into memory at once, the system performance could be greatly reduced as images are moved in and out of memory. This is the number one reason to reuse images when possible.