OpenGL es1.1.12 Chapter 2 2.1

(Draft only, not sorted)

Chapter 2

2 OpenGL ES running

2.1 Basic Principle of OpenGL ES

OpenGL ES (later called "Gl") is only concerned with rendering in the frame cache (and Reading saved values from the frame cache ). In some cases, peripheral devices related to graphic hardware, such as the mouse and keyboard, are not supported. Programmers must rely on other mechanisms to obtain input information, such as khronos openkodeapi.

The basic elements of GL painting depend on several optional modes. Each basic element is mainly a vertex, line, or triangle. Each mode can be changed independently, that is, one of the settings does not affect other settings. However, there are still many modes that will consider the impact to determine the final form of frame caching. Set the mode and define the basic elements and their GL operations as sending commands. The command form is function or process call.

A basic element is defined as a set that contains one or more vertices ). Vertex is a vertex, the end of an edge, or an angle of a triangle when both sides converge. Data (positional coordinates, color, orthogonal and texture coordinates) are associated with vertices. Each vertex is independent, ordered, and processed in the same way. This rule has an exception: If the vertex in the set is to be flipped (clipped), this means that the basic element is in a specific area. In this case, vertex data may be modified or new vertex data may be created. The flip type depends on which basic element is represented by the vertex set.

Commands are often processed in the order they are received. However, there may be uncertain latency before a command is identified. This means that a basic element needs to be painted before any subsequent command that will affect the frame cache. It also means that the returned status of the query and pixel read operations must be consistent with that of all previous GL commands. In general, the effectiveness of commands in GL mode and frame cache must be completed before any commands that may be affected subsequently.

In Gl, data is bound when a function is called. This means that when the command is received, the data passed to the Command has been parsed. Even if the Command requires a certain data point, the data will be parsed once the command is called, and any subsequent command changes will not affect the current GL, unless the same pointer is used in subsequent commands.

GL can directly control basic 3D and 2D operations. Including matrix transformation, Ray balancing coefficient, anti-sawtooth method, and pixel update operation. However, there is no way to describe or model a complex geometric object. In this case, GL provides a mechanism to describe how a complex geometric object is rendered, rather than a descriptive Mechanism for the complex geometric object itself.

The GL command mode is C/S. Programmers (clients) issue commands and GL (servers) Parse these commands. A server may maintain several GL contexts, each of which is an encapsulation of the current GL status. A client can select a context in connect. When no connection is established, the result of issuing a GL command is unknown.

The effect of GL commands on the frame cache is ultimately controlled by the frame cache resources allocated by the Windows system. Only the Windows system determines the frame cache part that Gl can access at a given time, and how it communicates with GL to organize these parts. Therefore, there is no GL command to set the frame cache or initialize GL. Simply put, displaying the content of a frame cache on an LCD panel or display (including graphic Correction Technology: converting the cached data of independent frames) is not controlled by GL. The frame cache configuration is performed outside the connection between the GL and the Windows system. The initialized GL context is performed when the Windows system assigns a window to the GL rendering. The egl API defines a portable mechanism to create a GL context and a window resource that can be used for rendering. This allows you to connect different original Windows platforms.

GL is designed to run on a series of graphic platforms with different graphic processing functions and performance. To achieve this goal, we define an ideal behavior rather than a realistic behavior to determine the GL operation. Therefore, deviations from these ideal states are acceptable. If it can be similar to ideal behavior, we also define the rules that must be followed to implement GL. In this way, diversity is allowed, that is, in the GL action, it means that when the same frame cache configuration is run with two identical inputs, there may be two different GL implementations that may not achieve pixel-to-pixel matching.

Finally, the command name, constant, and type are prefixed with GL (GL, GL _, GL in c). This can reduce the name conflict with other packages. For a clear description, these prefixes are omitted in this document.