The following pieces are required when putting the Engine on an embedded target:
In order to deploy the engine to an embedded target we must first decide which plugins are needed. The Engine is a self contained executable which loads plugins for added functionality. The Engine can be run as follows:
sbengine [-v] [-o] [deployment bundle]
-v verbosity, more v’s means more verbose output
-o plugin or manager options
Each plugin or manager can have specific options. The option string is defined as follows:
Each plugin or manager defines its name and possible options.
The filesystem path to the plugins, overrides the GRE_PLUGINS environment variable.
sbengine -omodel_mgr,plugin_path=/temp will set the plugin search path to the directory
The options for the Render Manager vary depending on the particular configuration used. The options for each configuration are described in the System Specific Requirements section of this document.
The size of the image memory pool in kilobytes
The size of the font memory pool in kilobytes
sbengine -oresource_mgr,image=4096 will set the image cache limit to 4K. By default there
is no limit on a particular resource.
Enables the rendering of a software cursor
Generate a completed event for every screen update
Disable the use of a particular hardware layer
The size of the event queue in bytes
sbengine -oio_mgr,queue_size=4096 will limit the event queue size to a
maximum of 4K. If the queue exceeds this size, events will be dropped and diagnostic messages will be
logged regarding the dropped events. The default behaviour is to have an unlimited event queue size.
The Storyboard product ships with a standard set of plugins which add functionality to the system. Plugins are loaded based on the GRE_PLUGINS environment variable. This variable can be a directory where all plugins are loaded from or a “;” separated list of plugins.
Some plugins have options that can be passed via the command line to the the plugin. To pass on option to a plugin use the -o option to sbengine in this format -o[PLUGIN_NAME],[PLUGIN OPTION]
Provides platform audio support.
This provides a contributed action
gra.audio that allows the user to play a single
asynchronous audio WAV formatted file.
Redirect events to another Storyboard IO channel. All events that are received are copied and tranferred directly to another channel without interpretation.
Capture mouse or touchscreen events and generate gesture events
What the gesture plugin does is to translates input
gre.move events from a mouse or a touchscreen in to a
gesture event. When a button is depressed, or your finger is dragged across the touchscreen,
the gesture plugin tracks it. When the button is release or your take your finger off of the
touchscreen, the plugin emits the gesture.
Gestures are made up of a series of numbers. The numbers represent the direction that the cursor was travelling as a grid arranged from 1 to 8:
Up and to the Right
Down and to the Right
Down and to the Left
Up and to the Left
By default the gesture plugin registers the Up, Right, Down, and Left gestures as 1, 3, 5, 7. The numbers 2, 4, 6, 8 aren't enabled by default, but you can define them in a custom gesture definition file. The gesture definition file is a text file that defines an event, followed by the gesture number.
For example, to define a
z gesture, you could put the following in the a
This definition stats when the gesture plugin detects a right motion, followed by a down and to
the left motion, followed by another right motion, it will emit a
You can point the gesture plugin at the custom gesture definition file by exporting the environment
GESTURE_DEF_FILE which will set to the path to the custom definition file.
Implement the Storyboard IO API and external application communication
The name given to the application's Storyboard IO channel.
sbengine -ogreio,channel=my_greio_channel would result in a Storybord IO
my_greio_channel to be used for this application. This channel name can
then be used by clients that want to connect and send events to the application.
Log system messages for debugging.
This option enables the logging of IO events to the output.
This option enables the logging of performance data to the standard output
(or file if
perf_file is used). If a value of 0 is specified to the perf option
then performance logging is enabled, but the capture of data is not immediately started
and can be toggled using the
gra.perf_state action. If the value is set
to 1 or is not specified, then performance data will be immediately captured. For
sbengine -ologger,perf=1 will enable performance logging with
the immediate capture of performance metrics.
This option specifies a path in the filesystem to direct the performance data output to. The directory path to the file must already exist and the contents of the file will be overwritten on each invocation of sbengine.
This option enables the logging of data change events to the output.
If IO logging is enabled then events and their data payload will be displayed as they are received. The data payload is dumped to the standard output in both hexadecimal and character formats.
If data logging is enabled, then data changes in the data manager will be displayed as they occur. The data key that has been changed is displayed to standard output.
If performance logging is enabled then the output is a set of comma separated values (CSV) with the following fields:
PERF, application time, type, operation, name, duration
This is the time that the performance event was finished relative to the start time of the application in milliseconds.
This is the type of performance operation that was recorded as a broad classifier
This is a sub-classification of the type used for additional tracing granularity
This is an identifier that can be used, along with the type and operation fields, to identify the context of the performance operation being perfomed.
This is the duration of the operation in milliseconds
The logger is disabled by default and can be enabled by passing
-ologger[,io][,data][,perf] to the sbengine application.
Transition from one screen to another in a path based method: Right, left, up or down
Transition from one screen to another by scaling the new screen to fill the display
Provide a virtual keyboard interface for WinCE clients using the Soft Input Protocol (SIP).
Allow external timer events to be used by the application. Adds support for
Add support for touchscreens using the Linux
tslib framework. This plugin available on Linux platforms only.
If you do not have the
tslib variables setup the plugin will not load or function properly.
Add support for Linux input devices such as mouse and keyboards based on the Linux input system.
The name of the mouse device, for example
The name of the keyboard device, for example
One of either the
kbd arguments must be passed to enable this plugin.
There are no default bindings so the full path to the desired input device must be specified.
Provides support for the polygon render extension.