Graphics Programs Reference
In-Depth Information
Thread Safety
When multiple threads access a static field:
1. Each thread may cache the field's value locally; as a result, when we
read its value from a thread (after it is updated), an old value can be
read. To avoid this, the static field is marked as volatile (this has
been used in the TOUCH ROTATION and SENSOR ROTATION applic-
ations). This forces the thread to read the global value of the field.
2. Threads might attempt to update the field simultaneously; as a result, a
race condition may arise, leading to an undesired value of the field. To
avoid this, a static object can be synchronized (as shown in the
UPDOWN COUNTER application) to ensure only one thread gets into
the synchronized block (at a given time).
Using static field(s) to share data is only an alternative to standard Java techniques
for cross-thread communication. We leave out the standard Java techniques to keep
you away from multithreading; we want to focus on ES 2.0 fundamentals on
Android. For most of our examples, the alternatives suffice, because, out of the two
threads (UI/main thread and renderer thread), only the former is updating the static
field(s).
Implemented Methods
The GLSurfaceView class requires a renderer that does the actual rendering; it
is specified using the setRenderer (GLSurfaceView.Rendererrender-
er) method. In the following sections, we talk more about the abstract meth-
ods— onSurfaceCreated , onSurfaceChanged , and onDrawFrame— inher-
ited by the class GLES20Renderer, which implements the interface GLSur-
faceView.Renderer .
Anatomy of a Renderer
While creating the GL SURFACE application in Chapter 1 , we intentionally sorted
the methods of the class GLES20Renderer in a specific order. We did so to signify
the actual sequence in which these methods get called. To understand this, we create
Search WWH ::




Custom Search