OpenGL ES programming guide for iOS Chapter 2

Document directory

• 2.2.1. client-server model
• 2.2.2. OpenGL ES depends on the key function libraries of specific platforms
• 2.2.3. commands can be executed asynchronously.
• 2.2.4. commands can be executed in sequence
• 2.2.5. parameters will be copied during the call
• 2.2.6. Define practical methods for expanding functions in specifications

Chapter 2 OpenGL ES on iOS

OpenGL ES provides the original functions of the program interface to accelerate the drawing of hardware pipelines through graphics. OpenGL consumes graphical commands to generate images for display to users, or further process searches other than OpenGL ES.

The OpenGL ES specification clearly states the behavior of each function. Refer to the following steps to understand most OpenGL ES commands:

· Refer to "determining OpenGL escapabilities" on the 25 th page for detailed practices.

· Read/write status variables are declared in the specification. The OpenGL ES status usually indicates the currently configured graphic pipeline. For example, OpenGL ES 1.1 uses state variables to extensively configure lighting, materials, and fixed function pipelines for computation.

· Create, modify, and destroy OpenGL ES objects. OpenGL ES objects are not objective-C objects; they are resources operated through OpenGL ES program interfaces. For more information, see "OpenGL ES objects encapsulate resources on behalf ofyour application" on page 17.

· Vertices need to be submitted to the pipeline for processing, combination, or writing through the original plot function as a caching frame.

2.1 which version of OpenGL ES should be selected?

When designing an OpenGL ES application, you must answer a key question: Your application must support OpenGL es2.0 or OpenGL ES 1.1 or both.

· OpenGL ES 2.0 is more powerful and flexible than OpenGL es1.1 and is the best choice for new applications. You can customize vertices and coloring devices more clearly and concisely, and have better performance. When performing the same computation in OpenGL es1.1, multiple rendering channels or more complex state configurations are often required to easily conceal the purpose of the algorithm. If the algorithm becomes more complex, the coloring machine of OpenGL es2.0 can better clearly and concisely express operations and improve efficiency. The establishment of OpenGL es2.0 applications requires a lot of work. By default, you need to re-create some basic configurations for OpenGL es1.1.

· OpenGL es1.1 provides some fixed functional pipelines, including some good basic 3D application functions, conversion and illumination, and hybrid caching. If the application requirements are simple, OpenGL es1.1 can be used for less encoding. To support all IOS devices, select OpenGL es1.1.

If you choose OpenGL es1.1 for device compatibility, you can consider adding an OpenGL ES 2.0 rendering option. OpenGL es2.0 has greater capabilities and advantages to use the graphics processor of the new iOS device.

ImportantIf your application does not support OpenGL ES 1.1 and 2.0 drawing paths, the installed version that the application can select will be limited. Refer to the "declaring the required device capabilities" section in iOS app programming Guild.

 

2.2. Understand the opengles Architecture

OpenGL ES operates in several key principles. To design an efficient OpenGL ES application, you need to understand the underlying architecture.

 

2.2.1. client-server model

OpenGL ES uses the client-server model, 1.1. When an application calls the OpenGL ES function, it will talk to the OpenGL ES client. After the client program calls the function, it is converted to OpenGL server commands if necessary. The client-server model allows job processing to be divided into client-side and server-side function calls. The essence of the client, server, and communication path between them. OpenGL ES has different practices. In iOS, the ultimate priority lies between CPU and dedicated graphics processor.

Figure 1.1 OpenGL ES client-server model

2.2.2. OpenGL ES depends on the key function libraries of specific platforms

The OpenGL ES specification declares how OpenGL ES works, but does not specify the function for managing the interaction between OpenGL ES and the main operating system. On the contrary, the specification assumes that each practice provides the configuration function of configuring rendering inner text and system render cache. Render the internal state of the OpenGL ES state machine. Each opengles application maintains its own copy of State data, so you don't have to worry about affecting other programs. For more information, see "processing OpenGL ES Contexts" on the 20-page ". You can also use multiple texts in a single application. The system compaction cache is the end point of OpenGL ES drawing commands and also related to the graphics subsystem of the main operating system. IOS does not provide system caching. On the contrary, IOS extends opengles's ingress cache object and allows data sharing with coreanimation. Refer to "framebuffer objects are theonly rendering target on iOS" on page 18 to get more information about the cached objects, the 28-page "Drawing with OpenGL ES" details how to create and use the volume cache in an application.

2.2.3. commands can be executed asynchronously.

One advantage of the OpenGL ES client-server model is that OpenGL ES functions can return control to the application before the request operation is complete. If OpenGL ES needs to wait for each function to be executed before returning control to the application, the CPU and GPU will be in the same step, and the application will lose many parallel opportunities. In iOS, it is common to postpone the execution of drawing commands. After several drawing commands are postponed and processed at the same time, the graphic hardware can delete hidden surfaces before performing expensive segment calculations. Many OpenGL ES functions send the refresh command to the graphics device either explicitly or implicitly. Other OpenGL commands for Refresh graphics processors will wait until some or all of the commands are completed. Avoid designing client-server synchronization applications as much as possible.

2.2.4. commands can be executed in sequence

If client applications take photos of functions in the same sequence, OpenGL ES ensures that the function call results are the same as those of xuanwen. When your application calls OpenGL ES functions, it can be assumed that the results of these functions are valid and the real-time commands have not been executed.

2.2.5. parameters will be copied during the call

For Asynchronous command processing, the parameter data required by the application to call the function must be copied before the control is returned to the application. If the parameter is a pointer to the vertex data array in the application memory, OpenGL ES must copy the vertex data before returning. This has some important significance. First, the application can freely change its memory regardless of whether or not it calls OpenGL ES, Because OpenGL ES will never access the memory with the application at the same time. Then, copy and format the data so that the graphical device can read and increase the call overhead of each function. For the best performance, the application must declare the data format optimized for the graphics device, and the buffer object should be used to hide the memory management and replication between the application and OpenGL ES.

2.2.6. Define practical methods for expanding functions in specifications

One OpenGL ES can demonstrate one of the two methods of OpenGL ES. First, the implementation must meet the minimum requirements stipulated by specifications, such as the texture size and number of texture units that can be accessed by applications. An OpenGL ES implementation freely supports large variables, such as a large texture or more texture units. Secondly, OpenGL ES extension allows a practice to provide the constant of the new OpenGL ES function. Expand to allow new features to be added in practice. Apple has implemented many extended features that allow applications to improve application performance using hardware features. The actual hardware restrictions of different iOS devices and versions are different from the list of extended functions provided. Applications must test the running capability to ensure consistent behavior.

2.3. Typical encapsulation of object Resources in OpenGL ES in applications

An object is an opaque container that is used to save the configuration status or data required by the Renderer in an application. Because only objects are accessed through program APIs, you can select OpenGL ES practices of different policies when configuring objects in an application. It can be stored in data format or memory location optimized by the prison processor. Another benefit of objects is repeated usage, allowing applications to configure objects once or multiple times.

The most important object types of OpenGL ES include:

L texture is an image that can be sampled by the drawing pipeline. Textures are usually used to map color images on primitives, but can also be mapped to other data, such as general ing or pre-computed lighting messages. Chapter "Best Practices for workingwith texture data" discusses the important topic of using texture on IOS.

L The buffer object is a block memory with OpenGL ES to store data in the application. Cache is used to precisely control the process of copying data between applications and OpenGL ES. For example, if you provide a vertex array, data must be copied every time you submit a drawing call. In contrast, if your application stores data in the vertex buffer object, the data is copied only when the application submits commands to modify the inner Text of the vertex cache object. Using Cache to manage vertex data can significantly improve application efficiency.

L vertex array objects are configured with vertex attributes read by graphic pipelines. Many application rendering entities require different pipeline configurations. By storing the vertex array configuration, you can avoid the cost of re-configuring the pipeline, and may allow specific vertex configuration optimization.

LShader programs), Or known as shaders, is also an object. OpenGL es2.0 allows you to create vertex and fragment coloring ers for vertex or fragment calculation respectively.

L The rendering cache (renderbuffer) is a special format for a simple 2D image. This format is usually defined as color, depth, or template data. Rendering cache is usually not used independently, but used together with the render cache (framebuffer.

LThe cached (framebuffer) object is the ultimate goal of the graphic pipeline. The cached object is just a container that contains the texture (texture) andRendering cache (renderbuffer), which creates the complete configuration of the Renderer. In the subsequent chapter "Drawing with OpenGL ES", we will discuss how to create and use the caching Cache Policy in IOS applications.

Although each object type in OpenGL ES has its own function to manipulate it, all objects share a similar programming model:

1.Generate Object Identity

Identity is a common integer used to represent a specific object instance. Every time you need a new object, call OpenGL ES to create a new identity. Creating an object identity does not represent creating an object. It is just a reference for configuration.

2.Bind an object to opengles

Most OpenGL ES functions implicitly act on objects, rather than explicitly specifying the object identity during each call. You set the object and bind it to the internal document. Different types of objects use different binding functions. When an object is bound for the first time, OpenGL ES configures and initializes the object.

3.Modify Object status

Your application enables one or more function calls to configure objects. For example, after a texture object is bound, texture filtering is usually configured and image data is read. Changing an object may be expensive because it may need to submit new data to graphic hardware. This is reasonable. Create and configure the object once and do not change it in the application.

4.Use object Rendering

Once you create and configure all the objects required for the rendering scenario, you need to bind the object for the pipeline and perform one or more drawing functions. OpenGL ES renders the data stored in the object according to the primitive. The result is sent to the bound ingress cache object.

5.Delete object

When the object is not used, the application should delete it. After an object is deleted, its content is destroyed and its identity is recycled.

2.4. Only the cache object (framebuffer) that is visible on iOS)

The cached (framebuffer) object is the target of the rendering command. The cached object provided by OpenGL es2.0 is part of the Core Specification. It is provided by the oes_framebuffer_object extension in opengles1.1. The cache objects of inway are only rendered on iOS. Apple ensures that oes_framebuffer_object expansion will be implemented in all

Practice OpenGL es1.1 on IOS. 1-2. The cached object provides color depth or template data storage to link the image to the cached object. The most common image link object is the rendering cache (renderbuffer ). However, OpenGL ES textures can be connected to the color attachment points cached by workers, allowing the image to be rendered directly as textures.
After that, the texture can be used as input for future rendering commands.

Figure 1-2: timeline cache and color and deep rendering Cache

Follow these steps to create the ingress cache:

1. Generate and link a shard cache object.

2. Generate, link, and configure images.

3. link the image to the tracking Cache.

4. Repeat 2-3 If you need more images.

5. Test the ingress cache integrity. Integrity rules are declared in the OpenGL ES specification. These rules ensure the ingress cache and its associated points.