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 draw 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.
GG supplies arender 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.
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.
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).
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.
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, and saving/loading polymorphic GUI elements to/from their serialized form. 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.