GG: Architecture

GG

- Main Page
- Related Pages
- Namespaces
- Classes
- Files

Architecture

# Rendering Overview

GG uses OpenGL to render its graphics. It is assumed that the entire GUI is being redrawn multiple times each second, as part of a high-framerate application. Each GG UI element is drawn using calls to OpenGL. Therefore, each element can be rendered as a pre-rendered pixmap, flat 2D texture or sprite, or even a fully 3D rendering; the complexity of the graphics used to represent the UI elements is only limited by the target rendering hardware and the user's skill.

# Integration With Application Render Loop

GG supplies a render loop in the form of GUI::Run(). For many applications, this default render loop is sufficient. However, for users who are integrating GG with an existing application that already has its own render loop, there is another way. See the GG::EventPump documentation for info on how you can update GG's GUI once per frame from your application's render loop.

# UI Overview

## Input Events

GG is organized as a layer on top of an existing user input framework. GG has no way of determining that a mouse click, mouse move, or any other user input event, has taken place. To use GG, one must subclass off of the abstract class GG::GUI, and define several of GG::GUI's pure virtual functions. These functions poll the underlying operating system or input framework, and generate GG input messages from them. Such messages are mouse moves and clicks, key presses and releases, joystick movement, etc. GG maintains internal state as to what part of the GUI is being dragged, clicked, etc.

## Example:

Suppose the user clicks the left mouse button at screen position (50, 37). GG will receive a message from the underlying application framework that a left mouse click has occurred; it then determines what UI element is under that screen location, if any. If it turns out there is a button under that spot, GG sets internal state indicating that the left mouse button is being held down, and that it is over the button. GG then sends a message to the button that it is depressed. The button sets its own internal state and returns. All processing is complete for this input; the next time the button is redrawn, it knows to draw itself in a depressed state. Very little computation is involved in processing a single user input event. GG's performance is therefore usually limited only by the application-defined processing that is associated with manipulating the controls (e.g., a button click may trigger disk IO).

## UI Element Connections

GG UI elements are connected using signals and slots, using the Boost.Signals library. This allows arbitrary connections between one control and another, and between a control and any other code; there is no hierarchy of passed messages as there is in some other GUIs, and no type-unsafe callbacks are used. Refer to the Signals and Slots documentation for details.

## GG::GUI Services

The singleton GG::GUI object is globally available through a static member function, GG::GUI::GetGUI(). This allows all code in the application to rely on GG::GUI for certain essential services. GUI-specific services include registering windows into the GUI, registering windows as always-on-top or modal windows, moving windows up or down in the z-order layers of the GUI, removing windows from the GUI, getting mouse state (position and button depression), setting mouse delay repeat (see GG::GUI for a description of this), entering and exiting from an orthographic projection (2D) rendering mode. Most of these services must be provided by the user when subclassing from GG::GUI; if either of SDLGUI or OgreGUI is used, these services are already implemented.

GG::GUI does a variety of things for the user, some of which are not strictly necessary for the core GUI functionality. GG::GUI provides limited timing info via FPS() and DeltaT(). These are provided to indicate how fast the GUI is rendering, and how long it has been since the last frame was rendered. There is also a font manager, an application-wide font "pool", from which the user can request fonts. The font pool loads and stores the fonts as needed by the application, and multiple requests for the same font at the same size will result in the creation of only one font object. A texture manager exists which does a similar job with textures. If the user wants to programmatically create textures, she can also add them to the texture pool, provide a name, and request that texture as many times as needed. OpenGL texture objects are used as the underlying texture rendering method.