All actions are executed within the context of an event delivery and as such their execution will have an impact on the overall throughput and responsiveness of the system. In particular with Lua scripts, it is important to limit the length of time that functions take to perform their work or to separate lengthy operations into separate tasks, threads or processes depending on the operating environment being used.
The screen manager listens for data changes and checks the state of controls to determine when the display needs to be refreshed. If the data for controls is changing rapidly this may cause thrashing of the display and possible flicker if not using double buffering. When changing data values, moving controls, or generating events which would cause the display to be updated, it is advisable to hold the screen manager updates until all changes have been made. Once modifications are complete the screen manager can be released and the display updated is needed. The actions are as follows:
Using the Storyboard logger plugin it is possible to capture metrics detailing various aspects of a Storyboard applications performance. These metrics include screen, layer and control redraw times, action execution times and general event processing times. If a performance log file is captured as and saved with the file extension .plog (for performance log) then Storyboard Designer will automatically recognize it and open up a log file viewer that provides an organized display of the performance events.
For more information on the performance monitoring plugin and its capabilities, refer to the Logger plugin section of this document and the gra.perf_state action.
The Storyboard Embedded Engine runtime also provides a number of internal variables that can be used at runtime to display performance information. The following Storyboard variables can be used to extract information from the runtime:
grd_fps (string, 1s0)
The frame rate of display updates averaged over the last 5 seconds of display. This value is only generated if the
-oscreen_mgr,fps option is passed along to the sbengine binary.
Storyboard display updates are entirely event driven, so unless the application that is being run is continuously changing content or generating redraw events such as is frequently done by benchmarking applications, this value may not reflect the true drawing performance of the system.
grd.animation.name (string, 1s0)
The name of the last completed animation.
grd.animation.frames (number, 4s0)
The number of frames rendered for the last animation run.
grd.animation.duration (number, 4s1)
The duration in milliseconds (ms) of the last animation run.
This sample demonstrates how you can use a Lua script to extract and print these values to the display.
function show_metrics(mapargs) local fps_key = "grd_fps" local name_key = "grd.animation.name" local frame_key = "grd.animation.frames" local duration_key = "grd.animation.duration" local msg local data = gre.get_data(fps_key, name_key, frame_key, duration_key) -- FPS generated every 5s, assuming: -oscreen_mgr,fps if(data[fps_key]) then msg = string.format("Screen FPS: %d", data[fps_key]) print(msg) end -- Animation data only available after animation complete if(data[name_key]) then msg = string.format("Animation %s took %d ms @ %d fps", data[name_key], data[duration_key], data[frame_key]) print(msg) end end
Choosing the Right Image Format(s) Bit Depth
When creating an application the developer must define the target system screen resolution and color depth. This color depth information is used internally to decide how to create and render display elements in an efficient manner. When adding images to the user interface it is always preferable to create them in the desired color depth. If the application will be running in 16bit color then the most efficient image to render will be a 16bit image. If alpha blending/transparency is not required when this image is rendered then it is advisable to create images in the application color depth or at least remove the alpha channel in the image.
Framerate (Frames Per Second)
Selecting an appropriate framerate for your screen transitions and animations will depend on your target system. You may think that selecting a higher framerate will make your animations run smoother, however, if your system can’t keep pace with the selected framerate, Storyboard Engine will drop the frames it can’t display in a timely manner. This will result in the engine having to do more work to achieve a lower framerate than intended and will look worse than originally setting a lower framerate that the target could handle.
A framerate of 14 frames per second will look good for the majority of simple animations. The results may vary, though, depending on what is being animated, how long it is being animated for, and what the content beneath the animated element is composed of. The best plan is to evaluate your design and animations on your target hardware, and tune your settings appropriately.
If you are only ever going to load an image once in you application don't scale the image, this is a performance hit at image render time. It's far better to use you favorite image editor and resize the image to exact size you intend to use it and turn the scale flag off.
Reducing Output Verbosity
Increasing the verbosity on
sbengine is insightful when trying to track down behavioral issues and to gain a better understanding of the system behavior. However, don't forget to turn off the verbosity for release since the process of outputting diagnostic messages to a console or serial terminal can cause significant slowdown due to the limited bandwidth of the output devices.
Adjusting Engine Rendering Options
The Storyboard Engine provides a number of different global rendering defaults that can be adjusted via command line options at execution time.
If your application contains a number of rotated images, then the
-orender_mgr,quality option can be used to trade between higher execution performance (0) and a better visual interpolation (2)
If your application is using an OpenGL renderer, then the
-orender_mgr,multisample option can be adjusted to favour less GPU consumption with less anti-aliasing (0) or choose a smoother visual presentation but longer to render (4 or more).
Managing Resource Memory
By default sbengine uses as much memory as it requires to load all the assets that the application requires (images, fonts, scripts,...) but this can be tuned to save memory. Here are some options to help with this.
- Remove any unused plugins from the plugins directory if you are simply setting a directory for the SB_PLUGINS environment variable.
- Set sbengine's
resource_mgroptions for image and font cache to appropriate values. Remember the caches must be large enough to fit all the images and fonts for your most resource intensive screen.
- Use the
Load Scaledflag in image render extension options if you are loading a scaled version of an image (e.g., an image thumbnails screen). If you are only ever loading the image once you should resize the image before deployment to avoid the runtime cost of image scaling.