The gifs that come pre-installed on the SmartMatrix seem to be playing great on my display, however I’m getting some glitches with some of my custom animated gifs. For example check out this Sonic gif. I’m getting color glitches when he runs and stops in the end. It plays fine on the PIXEL LED panel I have though. Any ideas?
I don’t have my SmartMatrix handy right now, but can you try this one? I opened it in GIMP, exported it, and chose to override all the frame disposal methods with replace instead of combine. No idea if that’ll fix it, but I can try it later. 
If the re-encoded GIF Jason posted doesn’t work, let me know.
The GIF Decoder on the SmartMatrix Display does a pretty good job of handling most GIFs, but every once in a while there’s some weird edge case that the encoder doesn’t fix. I’ll make a note to try to debug this GIF next time I’m working on the encoder.
Thanks Jason. That gif works! My original gif was built from microsofts old gif maker software. I just tried exporting it in Photoshop and while it works there, it has a silly 500 frame limit. Looks like I’m going to have to download GIMP and use it for all future animations for the SmartMatrix.
There’s actually one other thing I’m curious about. What’s the cause of the dim pixels that sometimes appear where it’s supposed to be black? It’s usually a couple of pixels on the outer edges or a line and always in the same spot each loop. Some gif animations with black backgrounds have this issue, others don’t. I also noticed this on the PIXEL, though in different spots.
It’s particularly noticeable at the beginning of this Atari Tutankham gif.
Is it a decoder thing or some limitation of LED matrices?
This has to do with how the panels are mutiplexed. You’ll probably notice the pixels appear in a column (actually in the SmartMatrix Display it’s turned 90 degrees, so it’s a row), as a lit pixel, and they don’t extend past the boundary between the 16th and 17th pixel where the multiplexing stops. I’m not sure exactly what causes this, but it’s not something that can be fixed through the panel’s interface or through software.
If that’s not what you’re seeing, can you post a video?
Yeah that’s definitely it. Did a search for led multiplexing and ghost pixels and I came across this:
Improperly designed LED-multiplexing circuits can create ghost images. Ghost images result when parasitic current flows through LEDs that are intended to be in an off state (i.e. no current flowing through them); this causes very faint illumination or ghosting. These ghost-image currents typically result from the discharging of stray capacitances associated with the large, common-LED anode-node tracks and the slightly forward-biased LEDs themselves.
Faint ghosting images from parasitic currents can occur when the multiplexing changes phases from MUX0-bar to MUX1-bar and vice versa. The effect is most pronounced when the LEDs on the multiplexed circuits are different colors (light wavelengths) and, hence, has significantly different voltage drops for a given current flow.
The ghost-image currents can be eliminated by providing a discharge path for the parasitic node capacitances and providing a time for the discharge to occur.
So I’m guessing the fix (if that really is a fix) would need to be implemented in the manufacturing stage of the LED matrix or the shield? Well, it’s not a huge annoyance and it only appears on certain images when there is a black background. Something I can work around.