PREV NEXT

Generic Logic, Inc. www.genlogic.com


1 Introduction to GLG

The GLG Toolkit is used to create sophisticated real-time animated drawings. The design of a GLG drawing allows developers to edit drawings simply and quickly, without re-programming, and allows many simple tasks to be controlled within the drawing itself, without programming at all. For example, GLG allows a developer to create a graphical input widget to accept input from a user, and to link that input to some drawing feature, without programming a single line of code.

The ease with which you can create new and elaborate drawings and the speed with which you can adapt existing drawings to new uses make GLG ideal for custom data display projects. Also, the flexible structure of the product makes it adaptable to many different real-time display applications. This allows the application programmer to concentrate on the data collection and management aspects of such an application, instead of the display.

Overview

GLG consists of several separate components:

Central to each of these components is the GLG drawing. Broadly speaking, the GLG Graphics Builder is for creating and modifying these drawings, and the API is for including and controlling the drawings from a user's program. (There is also an "intermediate" API for modifying a drawing from within a program, and an "extended" API for creating and adding objects to a GLG drawing at run time.) The widget set is a library of GLG drawings, and the tools are aids for creating and editing these drawings. Rather than relying on the sophistication of the editor or the API, however, it is the organization and internal structure of these drawings that gives GLG its power. Because of this, it is important for you to be familiar with the general structure of a GLG drawing before trying to use the Builder or the API. Fortunately, though the GLG approach presents a rich set of possibilities to the user, the structure is not a complex one.

The organizing philosophy of the GLG system might be described as a process of relentless abstraction. Wherever possible, GLG uses the same data structure to describe similar objects. For example, a point in space uses three numbers to specify its position: its X, Y, and Z coordinates. Similarly, a color is described as a collection of three numbers: the red, green, and blue values. In GLG, these two kinds of data are represented using the same data structure. Similarly, a straight line segment and a complex polygon appear similar within GLG. After all, a line is simply a two-point polygon

In addition to keeping the size of a GLG application small, this object-oriented approach provides a tremendous amount of flexibility. An operation defined on a polygon, for example, may equally well be applied to only one of its vertex points, or to a neighboring object, or to the properties of any other object, including a color. On the other hand, with this flexibility comes some complications. The approach can create some unexpected side effects (linking colors to positions in space is just one example), and one of the important consequences is that there are usually several different ways to solve the same problem.

The following sections describe the components of the GLG Toolkit in greater depth.

The GLG Graphics Builder

The GLG Graphics Builder is used to create, modify, and test GLG drawings. It is the most sophisticated graphics animation editor available in its class, and lets you create elaborately structured animated drawings, and to test them with intricate animation data-generated or real. Since all aspects of the object's appearance and dynamics are encapsulated as data, most of the object dynamics and behavior may be defined and prototyped in the Builder without any programming.

Elaborate constraints between objects' attributes may be created to define complex object behavior. The constraints may be later examined in the Builder using the constraints tracing options. A timer transformations may be used to animate objects without programming, for example, implementing blinking or animating fan blades in the drawing.

A variety of actions and custom commands can be attached to objects in the drawing to execute various actions at run time based on the user interaction, such as selecting an object with the mouse. A programming API is also provided to execute the actions under control of the application code.

The Builder's data generator may be used to animate objects in the drawing with simulated data in the prototype mode, and the Builder's resource browser presents the user with resource interface to the drawing - the same interface the application will use at run time. The Builder's tag browser allows the user to edit a list of data tags used for supplying data for animating the drawing at run time.

The GIS Zooming Mode of the Builder assists in the setup and prototyping of the integrated GIS mapping object.

The GLG HMI Configurator

The GLG HMI Configurator is a simplified version of the GLG editor which can be used by the end users to create GLG drawings using predefined components provided in the Widget Palettes. In addition to the standard GLG widgets, the palettes can contain custom OEM objects specific to the application domain. Custom widgets may define public properties for simplified editing.

The tag browser may be used to define tags for supplying data for animation at run time, and application-specific commands can be added to objects to be executed on a mouse click. In addition to the dynamics integrated into the widgets, predefined dynamics can also be added to objects to animate them based on real-time data.

Arbitrary drawings created in the HMI Configurator by the end user can be loaded in a GLG application and animated with the data sources defined in the drawing. An application can also execute action and commands defined in the drawing when the user interacts with the objects in the drawing with the mouse.

The SCADA Viewer Example

The SCADA Viewer demo provides an example of an application that loads arbitrary drawings, animates them with data sources defined in the drawing and executes actions and commands, such as displaying popup menus and dialogs, or writing data entered by the user to the process controller. The source code of the demo demonstrates how to query a list of data tags defined in the drawing and use it for animating the drawing with real-time data. It also shows how to process actions and commands defined in the drawing, and execute them under the control of the program.

Several versions of the SCADA Viewer with complete source code are provided for all supported GLG environments, including C, C++, C#, Java and JavaScript. A simplified version of the demo, a Simple Viewer, is also provided.

OpenGL or GDI (Native Windowing System) Renderer

OpenGL (Open Graphics Library) is a standard specification defining a cross-language cross-platform API for writing applications that produce 2D and 3D computer graphics. OpenGL is often used by 3D games and advanced graphical applications as an interface to the hardware accelerated graphics provided by modern graphics cards.

The OpenGL renderer is available for the GLG C/C++ applications on both Unix/Linux and Windows. On Windows, it is also available for the GLG ActiveX Control. Both the Graphics Builder and the GLG C/C++/ActiveX applications have a choice between the OpenGL renderer or a native windowing system (GDI) renderer, where GDI stands for Graphical Device Interface.

The OpenGL renderer uses hardware acceleration and enables such rendering features as antialiasing, true transparency and alpha-blending, native linear color gradients and hidden surface removal. The native windowing system renderer may be used as an alternative in cases when an application needs a greater consistency for rendering individual pixels regardless of the installed graphics cards. It may also be used as a fallback if the OpenGL renderer is not available. The software-based OpenGL can also be used for viewports that do not need frequent updates, or if the hardware OpenGL is not available.

The OpenGL driver supports both the Compatibility and Core OpenGL profiles. The shader-based Core OpenGL profile is used for OpenGL versions higher than 3.00, and the Compatibility profile is used for older OpenGL versions. The Core profile is used by default. If the Core profile is not supported by the graphics card, the driver will automatically fall back to use the Compatibility profile. If the hardware-accelerated OpenGL is not available, software OpenGL may be used to enable anti-aliased rendering at the cost of slower rendering.

The OpenGL renderer is used by the Toolkit in a transparent way, and the user does not need to know the low-level details of OpenGL graphics in order to benefit from the OpenGL's hardware acceleration and an extended set of rendering features. The same application executable may switch between using the OpenGL or native windowing renderer at run time, without any changes to the application code. The OpenGL renderer is supported in a cross-platform way on both Unix/Linux and Windows environments.

When the Toolkit is installed on Windows, two groups of icon shortcuts are provided for starting the demos and the Builder: one for the OpenGL rendering mode and another for the GDI mode. For Unix/Linux installations, symbolic links are provided for starting the demos and the Builder in either OpenGL or GDI rendering mode.

The following sections describe various options for configuring GLG OpenGL driver, as well as the command-line options, environment variables and global configuration resources that can be used to control the driver. Refer to the Command-line Options section on page 267 for a description of all command-line options. Refer to Appendix A: Global Configuration Resources of the GLG Programming Reference Manual for a list of supported environment variables and global configuration resources.

Java, C# / .NET and JavaScript Note: Java, C# and JavaScript environments use their own renderers that support anti-aliasing, transparency, alpha-blending and color gradients. The only feature of the OpenGL renderer not available in the Java, C# and JavaScript GLG applications is the hardware-accelerated hidden surface removal. For C#/.NET applications on Windows that need this feature, the GLG ActiveX Control provides an alternative to the GLG C# class library that supports OpenGL.

Enabling OpenGL renderer

The OpenGL renderer is enabled on per-viewport basis by setting viewport's OpenGLHint flag to ON. The flag may be set to several ON values with different rendering priorities described in the following section. If OpenGL is enabled in the drawing, but the graphics card does not support OpenGL, the Toolkit will automatically revert to the GDI renderer to render graphics.

At run time, the OpenGL renderer may be enabled or disabled by using the -glg-enable-opengl or
-glg-disable-opengl command-line options.

The OpenGL renderer may also be enabled or disabled globally, by setting the GLG_OPENGL_MODE environment variable to True or False, or programmatically, by setting the value of the GlgOpenGLMode global configuration resource to 1 or 0. The global configuration resource takes precedent over the command-line options, while the command-line options take precedent over the environment variable settings.

OpenGL Versions, Compatibility and Core Profiles

By default, the OpenGL driver uses the Core profile. If the graphics card does not support OpenGL version 3.00 and above, the driver will automatically fall back to use the Compatibility profile. The Core profile uses VBO-based retained mode and shaders, and does not provide immediate mode rendering. The retained rendering mode may provide performance improvements for drawings containing a large number of objects with static geometry. The retained mode may also significantly increase update speed of drawings with background images and text objects by storing cached textures on the graphics card. The retained mode is automatically activated when an OpenGL version 3.0 or higher is requested.

The GlgOpenGLVersion global configuration resource may be used to request a particular version of the OpenGL for the hardware-based version of the GLG OpenGL driver. For example, it may be set to a value of 330 to request OpenGL version 3.3. Alternatively, the GLG_OPENGL_VERSION environment variable and the -glg-opengl-version command-line option may be used to specify a desired OpenGL version.

The value of GlgOpenGLVersion is subject to the following thresholds:

If the requested OpenGL version is not supported by the graphics card, an error message is generated, and the driver is automatically downgraded to the highest supported OpenGL version.

Hardware and Software Renderers, OpenGL Priority

Each GLG viewport creates a window with its own OpenGL context, which limits the maximum number of viewports with the hardware-accelerated OpenGL an application can create. The exact maximum number is implementation-specific and varies depending on the graphics card, but it is usually greater than a hundred.

There are two ways to get around this limitation. For viewports with infrequent updates, an application can use software-based OpenGL which does not have a limit on the number of OpenGL contexts. Alternatively, GLG light viewports can be used for some widgets that would otherwise use regular viewports. Light viewports do not create its own window and use the OpenGL context of the parent viewport, and therefore are not subject to the limit on the number of OpenGL contexts.

GLG allows an application to combine both the hardware-accelerated and the software-based OpenGL renderers. A fast hardware-accelerated renderer may be used for main windows with lots of objects and fast update rates, while a slower software renderer may be used for icon buttons and other windows with small number of objects or with infrequent updates. As a result, applications with a large number of viewports can use OpenGL for all viewports without exceeding the limits of a graphics card.

At the design time, the application prioritizes viewports by setting the viewport's OpenGLHint attribute to one of several OpenGL priorities, from the highest (1) to the lowest (3). These priorities are used at runtime to determine the type of the OpenGL renderer (hardware or software) to use for each viewport. The hardware renderer is used for viewports with higher priorities, while the software renderer is used for viewports with lower priorities.

The GlgOpenGLHardwareThreshold and GlgOpenGLThreshold global configuration variables control the runtime mapping of the OpenGL priorities. All high-priority viewports with priority values less than or equal to GlgOpenGLHardwareThreshold will be rendered using the hardware OpenGL renderer. Low-priority viewports with priority values between GlgOpenGLHardwareThreshold and GlgOpenGLThreshold will be rendered using the software OpenGL renderer. Viewports with priority values equal 0 (disabled OpenGL) or greater than GlgOpenGLThreshold will use the GDI renderer.

The -glg-opengl-hardware-threshold and -glg-opengl-threshold command-line options, as well as GLG_OPENGL_HARDWARE_THRESHOLD and GLG_OPENGL_THRESHOLD environment variables may also be used to define the runtime mapping.

The global configuration resources and command-line options allow the user to change the runtime mapping on the fly. For example, if an application uses a small number of viewports, it can decide to use the hardware renderer for all its windows at runtime. If an application uses a large number of viewports, it can use software renderer for icon buttons and secondary viewports, while using faster hardware renderer for the main viewports. As a result, nice OpenGL anti-aliased rendering may be used for all application's viewports without exceeding the limits of a graphics card and its OpenGL driver.

The True or False setting of the GLG_DISABLE_HARDWARE_OPENGL and GLG_DISABLE_SOFTWARE_OPENGL environment variables, as well as the corresponding -glg-disable-hardware-opengl and -glg-disable-software-opengl command-line options may be used to disable either the hardware or software OpenGL renderer, in which case the remaining OpenGL renderer will be used for all OpenGL viewports regardless of the OpenGL threshold setting.

Shader-Based Anti-Aliasing

In the Core profile mode, the Toolkit's OpenGL renderer supports two line anti-aliasing techniques:

By default, the GLG OpenGL driver detects if the graphics card supports line anti-aliasing and switches to the shader-based anti-aliasing if the graphics card provides no support. If the quality of the resulting anti-aliasing is poor, the GlgOpenGLNativeLineAA global configuration resource and the corresponding GLG_OPENGL_NATIVE_LINE_AA environment variable (described in the Appendix A: Global Configuration Resources of the GLG Programming Reference Manual) may be used to explicitly define a desired line anti-aliasing mode.

OpenGL Setup and Diagnostics

To use hardware acceleration, a graphics card that supports OpenGL must be present and appropriate drivers must be installed. If the graphics card and/or drivers with the OpenGL support are not installed, a software OpenGL renderer will be used (always on Windows and Linux, and on other Unix systems - if available).

To check the status of the OpenGL renderer in the GlgBuilder, select the Options / Display OpenGL Info option from the main menu.

In both the Builder and the application, the -verbose command-line option may be used to display OpenGL diagnostic informations, including the version of the used hardware and software renderers. On Unix/Linux, the information will be printed to the terminal. On both Windows and Unix/Linux, the information will also be logged into the GLG log file named glg_error.log. The location of the log file is determined by the GLG_LOG_DIR and GLG_DIR environment variables as described in the Error Processing and Debugging section on page 49 of the GLG Programming Reference Manual. The verbose mode can also be activated globally by setting the GLG_VERBOSE environment variable to True.

The -glg-debug-opengl command line option and the GLG_DEBUG_OPENGL environment variable may be used to generate extended information from the OpenGL driver. The output is logged into the glg_error.log file in the GLG installation directory, and is also printed in the command window on Unix/Linux.

OpenGL on Linux Laptops with NVidia Optimus / Bumblebee

On Linux laptops with switchable graphics cards, the optirun command is used to run an application on the NVIDIA graphics card. The optirun utility preloads libGL, but not libGLU required by GLG. To run the Graphics Builder or a GLG application via optirun, libGLU has to be explicitly preloaded using the LD_PRELOAD environment variable. For example:

export LD_PRELOAD=/usr/lib/libGLU.so.1
optirun /usr/local/glg/bin/GlgBuilder

The Application Program Interface

Once a drawing is created, the GLG Toolkit offers a variety of ways to use that drawing in a program. Many of these methods are portable across window environments, allowing applications to be easily ported from X Windows to Microsoft Windows and back again.

Displaying a Drawing

The first step in using a GLG drawing from your application is to display the drawing on the screen. Again, depending on the application and graphical environment in which it will operate, you can choose one of several different display facilities:

GLG Wrapper Widget for C/C++ and X/Motif
You use the wrapper widget for applications that will operate in the X Windows environment. The GLG Toolkit supplies a version of this widget that uses Motif, and another that uses the Xt interface directly. You can use Motif if you want access to the Motif widgets, or if it's important for your application to use that graphical standard. The Xt version of the wrapper widget can also display and animate GLG drawings.
GLG Custom Control and GLG MFC Class for C/C# on Windows
This interface allows you to display and animate a GLG drawing in the Microsoft Windows environment.
Cross-Platform Generic API for C/C++
The functions of the GLG Generic API can be used to display and animate a GLG drawing in an entirely platform-independent way. A program using only functions from this API can work equally well in the Microsoft Windows and X Windows environments.
GLG Bean and GLG Class Library for Java
This 100% pure Java Class Library allows you to develop GLG applications using Java.
GLG User Control and GLG Library for C# and VB.NET
This is a native GLG C# Class Library for developing GLG applications using C# and VB.NET.
GLG ActiveX Control for C/C++, C# and VB.NET on Windows
This is an alternative option for developing GLG applications in C/C++, C# and VB.NET on Windows. It may be used to provide a hardware accelerated OpenGL renderer option for C# and VB.NET applications.
GLG JavaScript Library for Web Deployment on a Web page in a Browser
The GLG JavaScript API is a pure JavaScript library for client-side deployment of GLG applications in a web browser via HTML5 and JavaScript.
GLG Graphics Server for Server-Side Web Deployment via JSP or ASP.NET
The GLG Graphics Server provides either a Java or C# library for server-side web deployment of GLG applications via JSP or ASP.NET. While JavaScript provides a client-side deployment option with rich interaction capabilities, the server-side deployment option may be used for deploying existing Java or C# applications on the web in the viewing mode with minimal source code changes.

Animating a Drawing

Once a drawing is displayed, it may be animated by setting parameters of the drawing using either resources or tags.

Manipulating Objects in the Drawing at Run Time

The following GLG APIs extend the Standard API with additional functionality:

GLG Widgets

The Toolkit provides a variety of prebuilt widgets, such as dials, meters, buttons and toggles, charts, avionics, process control and electrical symbols, and many other widgets. Each widget is a GLG drawing that can be loaded and customized in the GLG Builder. Custom widgets can be created by either modifying an existing widget, or created from scratch using the Enterprise Edition of the Builder.

In the Builder, widgets are available for drag and drop via the widget palettes. Custom palettes can also be integrated into the GLG Builder and HMI Configurator.

Programming Tools

The GLG Toolkit includes several programming tools useful to application programmers. These include a test data generator, a file format converter, and a code generator for including a GLG drawing directly within an application's code. The GLG Graphics Builder and file converter may also be used as scripting tools, for editing drawings using a script in batch mode, or to create new drawings using a script. Refer to the GLG Programming Tools and Utilities of the GLG Programming Manual for more information.


Generic Logic, Inc.
www.genlogic.com
PREV NEXT