Persistence, Part II
A few more words and details about the Persistence of Vision hack previously mentioned. Pictured at left is a screen-shot of the application in operation. The astute observer will note that there’s enough room for at least 3 more columns to the right of the one on display, and may even wonder why I didn’t incorporate that space as well. Honest truth is I did – but the switching time (based on navigating the object model behind the scenes) was painfully slow when the additional 18 cells were added to the process, enough so that the entire effect was rendered defunct (the speed required for movement to match the manifest processor lag was slow enough as to nullify the PoV phenomenon). While it may be possible via native code (sans-framework) and/or enhanced algorithms to achieve a sufficient switching rate, the refresh rate of the screen still poses problems.
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…
Solutions
- 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.
Leave a Reply