The photos of the demo operation in the original article testify of this. Looking closely, there are a few instances where one of the 5 columns composing the virtual letter is absent even in the interior (not on the edge of either the wave or the letter). This demonstrates the mismatch between target refresh rate and screen draw/refresh. Also in that picture my fingers were being held such as to cover the battery/status bar visible at the top of the screenshot (although imperfectly, as evidenced by the tracer in the demo photo). All this griping and analysis is fine for diagnosing the problem, but doesn't do anything to improve chances for success other than defining a starting point. So...
- Full-screen draw available via native libraries (eliminates the battery/status bar)
- Improved drawing routines (faster object navigation via native libraries, bitwise AND comparison to minimize number of addressed cells per call, etc.)
- Automatic brightness control (demo was taken at half-brightness w/auto adjust turned on - sub-optimal test, and an error of omission on my part).
- Processor and/or screen overclocking (don't know if this one is possible yet) OR tapping into hardware accelerated GL routines for performance
- Not being so @#$& picky.
I'll state for the record here that I have satisfied my original curiosity in the exercise and do not anticipate investing the time to explore the above (or other) solutions. I'm willing to let this one die on the floor and move on to the next project(s) I have in mind, which may or may not eventually be disclosed here. Anybody interested in the source code to this point is welcome to contact me.