Measuring the timing with a logic analyzer. Without a solution to our tearing problem, we will see anything but an ideal squarewave. Anyway, for stuff like temporal dithering for 4 or even 8 “colors” it´s already good enough. 
@Stefan_Petrick Yah fair enough, just curious what you’d see. You might even see just a slow 30 hz update rate with random sections of on/off throughout.
I’ve even contemplated using a photocell to query when something goes bright to measure the sync state, periodically.
It would mean a bright flash periodically (and/or sacrificing a corner of the screen).
With an aperture time of 1/100 s the all black/all white change at 870 fps looks like this: http://fs5.directupload.net/images/160203/kmzc5dv9.jpg
Great photo.
You’ve actually got me thinking I might be able to do screen syncing by monitoring the lower corners of a large enough oled module with photosensors (one in each bottom corner) for my application.
No syncing yet, but I found a way to make the display show stuff faster. They keys are the clock divide ratio and the oscillator frequency. Both controlled by D5h. This seems to be the maximum:
display.ssd1306_command(0xd5);
//display.ssd1306_command((ratio & 0x0F) | ((frequency & 0x0F) << 4));
display.ssd1306_command(0b11110000);
Poor video quality but anyway: https://www.youtube.com/watch?v=Xh9_JUiUiNg&feature=youtu.be
@Stefan_Petrick The fact that its scrolling horizontally means its more than just a tearing issue. Looks like the data just isn’t getting clocked in properly at that speed Id guess.
@Stefan_Petrick : Using the Arduino built-in analogRead() function like that might be slowing you down by switching one ADC multiplexer between input pins (I know this takes time on AVR, not sure about Teensy3). It might run faster if you sample A1 all 7 times, then sample A2 7 times (if you can wire it like that).
Otherwise, there’s an ADC library[1] that’s built around using multiple ADCs on the Teensy3.1/3.2, which ought to speed up your measurements even more. Not only does it save you from having to switch the multiplexer every read, but it also runs both ADCs simultaneously with one call to adc->analogSyncRead(pin1, pin2).
[1] http://forum.pjrc.com/threads/25532-ADC-library-update-now-with-support-for-Teensy-3-1
@Stefan_Petrick Are you interested in performing a small test?
If you change the mux ratio from default of 64, to a smaller number, the actual frame refresh rate should increase proportionately.
The cost is fewer lines displayed on screen.
If you set the mux to 32 for example, do you get a clean visual for one half of the screen?
I think in your code it would look like:
display.ssd1306_command(0xa8); // Set Multiplex Ratio
display.ssd1306_command(31); // 32 rows, default is 63 (64 rows)
Im considering getting new haven 1.5" ssd1353 oled module, with parallel interface.
If my calculation is correct I can get 256 frames @ 16 bit color @ 96 x 64
http://www.newhavendisplay.com/NHD_forum/index.php/topic,1683.0.html
Thank you,
Rob.
Technical question about screens. I am going to order some to test your code and visualizations, so my question - should I just get this OLED displayed, or maybe should I order some others too that you maybe consider using in near future in your project(s)? Just to be prepared 
Thanks!
From everything I had my hands on an OLED with a SPI interface was the fastest solution I found so far. @Juris_Perkons
Thanks. I guess what I was trying to ask is - maybe You have plans to use any bigger SPI OLED screen (that I also should order just in case)? Thanks again.