open Gl ES

Understanding the OpenGL ES Architecture

Client-Server Model

OpenGL ES uses a client-server model, as shown in Figure 1-1. When your application calls an OpenGL ES function, it talks to an OpenGL ES client. The client processes the function call and, where necessary, converts it into commands to deliver to the OpenGL server. A client-server model allows the work to process a function call to be divided between the client and the server. The nature of the client, the server, and the communication path between them is specific to each implementation of OpenGL ES; on an iOS device, the workload is divided between the CPU and a dedicated graphics processor.

Figure 1-1  OpenGL ES client-server mode

l

A rendering context stores the internal state for the OpenGL ES state machine. Rendering contexts allow each OpenGL ES application to each maintain a copy of the state data without worrying about other applications.

A system framebuffer is a destination for OpenGL ES drawing commands, and is typically associated with the host operating system’s graphics subsystem. iOS does not provide system framebuffers. Instead, iOS extends the framebuffer object provided by OpenGL ES to allow framebuffers that share data with Core Animation.

The most important OpenGL ES object types include:

• A texture is an image that can be sampled by the graphics pipeline. This is typically used to map a color image onto primitives but can also be used to map other data, such as a normal map or pre-calculated lighting information. The chapter “Best Practices for Working with Texture Data” discusses critical topics for using textures on iOS.

• A buffer object is a block of memory owned by OpenGL ES used to store data for your application. Buffers are used to precisely control the process of copying data between your application and OpenGL ES. For example, if you provide a vertex array to OpenGL ES, it must copy the data every time you submit a drawing call. In contrast, if your application stores its data in a vertex buffer object, the data is copied only when your application sends commands to modify the contents of the vertex buffer object. Using buffers to manage your vertex data can significantly boost the performance of your application.

• A vertex array object holds a configuration for the vertex attributes that are to be read by the graphics pipeline. Many applications require different pipeline configurations for each entity it intends to render. By storing a configuration in a vertex array, you avoid the cost of reconfiguring the pipeline and may allow the implementation to optimize its handling of that particular vertex configuration.

• Shader programs, also known as shaders, are also objects. An OpenGL ES 2.0 application creates vertex and fragment shaders to specify the calculations that are to be performed on each vertex or fragment, respectively.

• A renderbuffer is a simple 2D graphics image in a specified format. This format usually is defined as color, depth or stencil data. Renderbuffers are not usually used in isolation, but are instead used as attachments to a framebuffer.

• Framebuffer objects are the ultimate destination of the graphics pipeline. A framebuffer object is really just a container that attaches textures and renderbuffers to itself to create a complete configuration needed by the renderer. 

EAGLContext* CreateBestEAGLContext()

{

EAGLContext *context;

context = [[EAGLContext alloc] initWithAPI:kEAGLRenderingAPIOpenGLES2];

if (context == nil)

{

context = [[EAGLContext alloc] initWithAPI:kEAGLRenderingAPIOpenGLES1];

}

return context;

}

Important When you tune your application’s performance, the first step is usually to determine which stage the application is bottlenecked in, and why.

Figure 6-1  OpenGL ES graphics pipeline