Horizontal update tearing

21

Thanks, I pasted your code into the GitHub issue so I wouldn’t lose it.

If you have time and want to share more, please send me some info, or just create a new post here. I don’t think I’ve seen anyone else connect up an ESP8266 to the SmartMatrix, so I’m interested to learn more.

22

Ok cool :smile:

I am in the process of finishing the configuration tool that is used to initially set up the wifi and adjust various delays / animation speeds and colours the departure board uses. Once I have everything working correctly I will post more information about the project. Also waiting for my custom PCB to turn up :smile:

Regards
Russell

23

This tearing at scan boundaries has been annoying me. For my 64 row matrix, there’s ~4ms between row 32 and row 31 being lit. I figured a different scan order could reduce the maximum period between adjacent rows to 0.25ms, and eliminate that annoying offset in the middle. To test that theory out, I made this change.

Here are before and after photos of this sketch, along with exaggerated impressions of how a fast moving vertical line looks to my eyes.

image
image703×351 71.5 KB

I find this much less jarring than the original discontinuity.

24

Nice! What refresh rate are you using?

I tried an alternate scan order in the past (I used the same order as an interlaced GIF) and it was way worse in my opinion, but I’ll have to try this and see how it compares.

25

I use 240Hz - 280Hz refresh usually, although those photos were taken using 60Hz in an attempt to capture an image representative of what I see.

Yes, I can imagine the progressive GIF scan may have looked worse than the raster scan. Adjacent rows would have had up to 2ms between them.

edit: now I’ve taken the time to add Serial.println(matrix.getRefreshRate()); I see that I was actually running at 170Hz for that sketch. I didn’t realise 7 ScrollingLayers would be that expensive.

26

I’ve spent some time testing this more thoroughly, throwing many different sketches, shaders and music videos at it. I can’t go back.

Cons:

  • Fast moving straight lines show subtle shearing. Probably not noticeable unless you’re looking for it. This shear was present previously, but now it’s twice as steep.
  • When your eyes track a moving object, a static background shows 2x steeper shearing.

Pros:

  • No in-your-face tearing!
  • Strobe effects now appear to light the whole panel at once, rather than flash the halves sequentially.
  • When the panel is in the periphery of my vision, I no longer see it as something falling. I guess because there’s no net downward motion to the scan pattern.
  • Colour uniformity seems better, at least for my non-ideal power arrangement. Consider a large white square, centred vertically with some black rows above & below. Some “scan rows” will illuminate only rows in the top half, some only in the bottom half, and some both halves. Previously this lead to the centre rows of the square being brighter than the top & bottom. This effect is far less pronounced now, presumably because interleaving the scan gives the voltage time to recover.
  • It’s vertically symmetric, so it should hide tearing at the boundaries of (at least some) multi-panel arrangements. I don’t have the hardware to test this. I think this works unchanged for arrangements with rotated panels.

If you like the results too, I can try to put a PR together to apply this to all the places it needs to be, maybe even with a #ifdef SM_ALTERNATE_SCAN_ORDER to default to the previous behaviour. Unless you’d rather do it yourself. I must admit I looked briefly at the multi-row refresh code and ran away. I’m not sure whether it even makes sense for those types of panels.