Shader workflow -- The "underlying reasons"

Recap of last week's work.

After few days of serious thinking, I decided to implement the GPU flow in the underlying C loop of the FCam application, rather than the OnDrawFrame rendering thread on Java. Here was my pro/con list:

Java:

• The rendering thread already makes use of the GPU. Having multiple GPU access points, i.e. in the Java thread and the C loop, seemed redundant. I was annoyed, for instance, at the prospect of having to do multiple RGB<-->YUV conversions.
• We had already worked on a shader in Java-side.
• On the Java thread after "TripleBuffer", I didn't know how to implement multiple frames for flash/no-flash fusion.
• I also did not figure out how to do multiple shader passes on the same image.

C:

• Full control. I knew how to do multiple SharedBuffers, as well as how to do multiple shader passes.
• I realized that I did not have to do the RGB conversion if I didn't want to, even if the buffer itself was set up as 4-byte RGBA (8888). I would just use the R byte for Y, G for U, etc.
• I personally prefer C to Java.
• Had to do an extra copy of the image from 'frame.image' to the SharedBuffers.
• Multiple places in code access GPU (C and Java). Maybe a bit less elegant.

Ultimately, I had to choose the C implementation because I had spent at least one full day and could not figure out how to do multi-pass shading in Java. I had not even attempted to figure out how to do multiple frame-buffers (for flash/no-flash fusion).

The shader pipeline in the C thread looks like the following: