No announcement yet.

OLED-160-G2 slows down during animated gif

  • Filter
  • Time
  • Show
Clear All
new posts

  • OLED-160-G2 slows down during animated gif


    I have the OLED-160-G2, and I'm now playing with putting animations on it. I have an animated gif (289 frames) that I created and loaded it to the raw SD card and wrote some very basic code to display it (a for next loop 0-288 to help display the frames and a pause(50) between each frame.) It all loads and runs with no errors.

    What happens is that the first time through the animation, it's very snappy, moving at a good pace. Then when the second iteration begins, the frame rate drops about 30%-50%. I need to put a timer on it to see if it continues to degrade through additional iterations, but it's VERY noticeable with the second time through.

    Ideas on what might be causing this? What additional info might you need from me to help?

    Uncle Rogi

  • #2
    Sorry, no real idea.

    Could you zip everything up and attach it here? (or email it to mark at 4dsystems dot com dot au, if you would rather not post it)

    The display should be doing everything the same.

    I wonder if the uSD card has some internal cache that is being 'missed' for the second cycle, although I have never seen anything like this before.

    What brand and model of uSD card are you using?


    • #3
      Interesting question about the SD card - there doesn't appear to be a brand on it. All it shows is 2GB MicroSD. I can't for the life of me remember where I got it. It's the only 2GB card I've got. I've got several 16/32/64GB cards, but didn't want to devote such a large card to such a small file/project. If your test results differ from mine, I can certainly either buy another small one (super cheap) or use one of my other cards.

      I'll zip the project and gif with a pic of the card and a video of my results and email it to you. Timing wise, it was worse than I thought - 1st iteration was ~11 seconds in duration, 2nd iteration was ~26 seconds in duration. Huge difference.



      • #4
        Hmm, the first time you do the video you use media_Video(), the second time you use a loop of media_VideoFrame(); with a pause(50); between each frame.

        For media_Video() the display starts a timer as it begins each frame and will wait until that timer expires after the frame has been displayed.

        For historical reasons Workshop generates all videos with an inter-frame delay of 1ms, this effectively means that the videos run at full speed with no delay, regardless of the delay specified in the video. This was done because people just didn't seem to understand that it took time to display each frame and that lowering the frame delay, past a certain point, made absolutely no difference to the speed of the animation as it was already going 'full speed'.

        So, your first run is taking, by my measurements, 11.546 secs, or 39.95ms per frame.

        The second run should then take 11.546secs + 50ms * 289frames or about 25.996seconds

        I measure 26.597 which roughly ties in, because a) using VideoFrame is a bit slower than Video and b) the timer resolution means a bit of time can be lost with each pause().

        You can say gfx_FrameDelay(100) ; before you do media_Video to enforce the 100ms delay from the start of one frame to the next (This will have no effect on media_VideoFrame)

        You can also play with that value a bit, you will see that any value below 40 makes no difference to the time the video takes to display.

        Also, since we know each frame takes about 40ms we can calculate that a value of 90 will result in the speed being approximately the same for both the first and second techniques.

        Hope that all makes sense



        • #5
          Thanks Mark - Wow, I didn't even notice that two different commands were being used to display the video - the first one was inserted by the Visi system (which I admit that I totally ignored) and I manually coded the second based on some tutorials from the site. Totally got past me.

          Ultimately, I want to introduce longer delays at certain key frames, so for that, I would need to use the media_VideoFrame loop method coupled with a switch statement to catch the key frames (and comment out the media_Video command.)

          I just updated the code to do that and it looks good. Is there a better way to do that?



          • #6
            Switch statement is fine, depends on how many different types of pauses you need, of course.

            Plain old ifs or lookup16 are other techniques.