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).

Static vs. Dynamic

In the drawing system there are two fundamental concepts that apply to all screen objects, whether the object is static or dynamic. This one aspect will provide a large difference in performance if managed properly. The primary difference is static objects are drawn seldom, only when a change is needed, where dynamic objects are drawn every frame of the main loop.

Each layer has a property called “Texture View” as a checkbox when the layer is right-clicked on. If a layer has “Texture View” enabled, then static and dynamic objects will behave differently. If a layer has “Texture View” disabled, all graphics objects on that layer are automatically treated as dynamic whether they are marked static or not and drawn each frame update.

If a layer has “Texture View” enabled, the layers below it will not be visible and should be disabled by moving them to a page with a view that has no objects and is marked False in the “Show In View” option in the Page Properties section.

Within a layer, all static objects will draw first then all dynamic objects will draw. See list below for different objects and their corresponding type.

If a layer has “Texture View” enabled, performance speedup is obtained by this sequence drawing:

1. Static objects are drawn only if a static object has changed in the scene (shown or hidden)
2. The interim frame of the static objects drawn is saved in a buffer to be used in later frames
3. Dynamic objects are drawn
4. On subsequent frames, only the static buffer is drawn for all the static objects if none have changed and then the dynamic objects are drawn.

Objects on the screen have different properties that cause them to be in the “static” group or “dynamic” group. Some objects like rotary gauges and bar gauges are automatically split internally with parts in the static section and parts in the dynamic section. See this table for properties of screen objects:

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.