<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
<title>GG: Architecture</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<link href="doxygen.css" rel="stylesheet" type="text/css" />
</head>
<body>
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
<tbody>
<tr style="height: 56px;">
<td style="padding-left: 0.5em;">
<div id="projectname">GG
</div>
</td>
</tr>
</tbody>
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.8.1 -->
<div id="navrow1" class="tabs">
<ul class="tablist">
<li><a href="index.html"><span>Main Page</span></a></li>
<li class="current"><a href="pages.html"><span>Related Pages</span></a></li>
<li><a href="namespaces.html"><span>Namespaces</span></a></li>
<li><a href="annotated.html"><span>Classes</span></a></li>
<li><a href="files.html"><span>Files</span></a></li>
</ul>
</div>
</div><!-- top -->
<div class="header">
<div class="headertitle">
<div class="title">Architecture </div> </div>
</div><!--header-->
<div class="contents">
<div class="textblock"><h1><a class="anchor" id="arch_rendering"></a>
Rendering Overview</h1>
<p><a class="el" href="namespaceGG.html" title="The namespace that encloses all GG classes, functions, typedefs, enums, etc.">GG</a> 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 <a class="el" href="namespaceGG.html" title="The namespace that encloses all GG classes, functions, typedefs, enums, etc.">GG</a> 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.</p>
<h1><a class="anchor" id="arch_main_loop_integration"></a>
Integration With Application Render Loop</h1>
<p><a class="el" href="namespaceGG.html" title="The namespace that encloses all GG classes, functions, typedefs, enums, etc.">GG</a> 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 <a class="el" href="namespaceGG.html" title="The namespace that encloses all GG classes, functions, typedefs, enums, etc.">GG</a> with an existing application that already has its own render loop, there is another way. See the <a class="el" href="classGG_1_1EventPump.html" title="Encapsulates the GG event-pumping mechanism.">GG::EventPump</a> documentation for info on how you can update <a class="el" href="namespaceGG.html" title="The namespace that encloses all GG classes, functions, typedefs, enums, etc.">GG</a>'s GUI once per frame from your application's render loop.</p>
<h1><a class="anchor" id="arch_UI_overview"></a>
UI Overview</h1>
<h2><a class="anchor" id="arch_input_events"></a>
Input Events</h2>
<p><a class="el" href="namespaceGG.html" title="The namespace that encloses all GG classes, functions, typedefs, enums, etc.">GG</a> is organized as a layer on top of an existing user input framework. <a class="el" href="namespaceGG.html" title="The namespace that encloses all GG classes, functions, typedefs, enums, etc.">GG</a> has no way of determining that a mouse click, mouse move, or any other user input event, has taken place. To use <a class="el" href="namespaceGG.html" title="The namespace that encloses all GG classes, functions, typedefs, enums, etc.">GG</a>, one must subclass off of the abstract class <a class="el" href="classGG_1_1GUI.html" title="An abstract base for an GUI framework class to drive the GG GUI.">GG::GUI</a>, and define several of <a class="el" href="classGG_1_1GUI.html" title="An abstract base for an GUI framework class to drive the GG GUI.">GG::GUI</a>'s pure virtual functions. These functions poll the underlying operating system or input framework, and generate <a class="el" href="namespaceGG.html" title="The namespace that encloses all GG classes, functions, typedefs, enums, etc.">GG</a> input messages from them. Such messages are mouse moves and clicks, key presses and releases, joystick movement, etc. <a class="el" href="namespaceGG.html" title="The namespace that encloses all GG classes, functions, typedefs, enums, etc.">GG</a> maintains internal state as to what part of the GUI is being dragged, clicked, etc.</p>
<h2><a class="anchor" id="arch_UI_overview_example"></a>
Example:</h2>
<p>Suppose the user clicks the left mouse button at screen position (50, 37). <a class="el" href="namespaceGG.html" title="The namespace that encloses all GG classes, functions, typedefs, enums, etc.">GG</a> 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, <a class="el" href="namespaceGG.html" title="The namespace that encloses all GG classes, functions, typedefs, enums, etc.">GG</a> sets internal state indicating that the left mouse button is being held down, and that it is over the button. <a class="el" href="namespaceGG.html" title="The namespace that encloses all GG classes, functions, typedefs, enums, etc.">GG</a> 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. <a class="el" href="namespaceGG.html" title="The namespace that encloses all GG classes, functions, typedefs, enums, etc.">GG</a>'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).</p>
<h2><a class="anchor" id="arch_UI_element_conns"></a>
UI Element Connections</h2>
<p><a class="el" href="namespaceGG.html" title="The namespace that encloses all GG classes, functions, typedefs, enums, etc.">GG</a> 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 <a class="el" href="sigs_n_slots.html">Signals and Slots</a> documentation for details.</p>
<h2><a class="anchor" id="arch_gui_services"></a>
GG::GUI Services</h2>
<p>The singleton <a class="el" href="classGG_1_1GUI.html" title="An abstract base for an GUI framework class to drive the GG GUI.">GG::GUI</a> object is globally available through a static member function, <a class="el" href="classGG_1_1GUI.html#aba6ef97f17ae5426c89e700571b77954" title="allows any GG code access to GUI framework by calling GUI::GetGUI()">GG::GUI::GetGUI()</a>. This allows all code in the application to rely on <a class="el" href="classGG_1_1GUI.html" title="An abstract base for an GUI framework class to drive the GG GUI.">GG::GUI</a> 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 <a class="el" href="classGG_1_1GUI.html" title="An abstract base for an GUI framework class to drive the GG GUI.">GG::GUI</a> 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 <a class="el" href="classGG_1_1GUI.html" title="An abstract base for an GUI framework class to drive the GG GUI.">GG::GUI</a>; if either of SDLGUI or OgreGUI is used, these services are already implemented.</p>
<p><a class="el" href="classGG_1_1GUI.html" title="An abstract base for an GUI framework class to drive the GG GUI.">GG::GUI</a> does a variety of things for the user, some of which are not strictly necessary for the core GUI functionality. <a class="el" href="classGG_1_1GUI.html" title="An abstract base for an GUI framework class to drive the GG GUI.">GG::GUI</a> 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. </p>
</div></div><!-- contents -->
<!-- start footer part -->
<hr class="footer"/><address class="footer"><small>
Generated on Fri Jun 15 2012 15:13:31 for GG by  <a href="http://www.doxygen.org/index.html">
<img class="footer" src="doxygen.png" alt="doxygen"/>
</a> 1.8.1
</small></address>
</body>
</html>
