Jump to content
Iamattamai

Flickering PNG Sequence

Recommended Posts

Okay, I tried to create a CodePen for this but it was too big and I didn't know how I could reduce the size and still replicate the problem.

I am including an AWS link instead - hope that is allowed: https://s3.us-east-2.amazonaws.com/image-store-21/hackathon/A06-2.html

 

Here is what I am doing:

I am loading a sequence of png images in base64 and hiding visibility for all before executing the JS.

I am using staggerto to flip each image in the sequence from hidden to visible then back.

For the most part it all works...

My problem is this: randomly during playback you will see a very momentary and annoying 'blink' during the staggerto repeating sequences where it seems the image momentarily fails to display on time.

It is more pronounced with larger examples of this containing greater number of images and sequences - you may need to run it several times to see it.

I have tried tweaking the timings without success.

I have also tried toggling opacity and autoAlpha instead of visibility without any noticeable effect.

Hoping someone can help me understand how to smooth it out.

 

Thanks in advance.

 

Share this post


Link to post
Share on other sites
12 minutes ago, Iamattamai said:

I am loading a sequence of png images in base64 and hiding visibility for all before executing the JS.

 

Have you tried not using base64? I would recommend using a sprite sheet for something like that.

  • Like 4

Share this post


Link to post
Share on other sites

Hey Iamattamai, 

 

This seems like it's an issue with the images loading to me, not an issue with GSAP. I'd recommend using a sprite sheet as Blake suggested. If you can't do that from some reason it might help to make sure the images have loaded

  • Like 4

Share this post


Link to post
Share on other sites
Posted (edited)

I have an onload event set for the body - doesn't that guarantee that the images are loaded?

Also, the blinks are happening in the middle of repeating sequences, not where there are transitions to new sequences.

My own suspicion is that it is a processor issue, but just guessing.

I was hoping there might be a way to 'overlap' the reveal/hide just very slightly to reduce any momentary delay as one suggestion.

I just couldn't get anything like that to work.

Also, there is a design requirement for a single file mandating base64.

A spritesheet is just about loading mostly, right? Is there any reduced processing overhead?

Edited by Iamattamai
additional info

Share this post


Link to post
Share on other sites
54 minutes ago, Iamattamai said:

I have an onload event set for the body - doesn't that guarantee that the images are loaded?

 

No. A window load listener will if the images are in your markup. Another way is to add listeners to all your images and wait for all of them to finish.

 

54 minutes ago, Iamattamai said:

Also, there is a design requirement for a single file mandating base64.

 

Not sure how base64 is a design requirement as that has nothing to do with design. And you don't have a single file. You have multiple files, and base64 has a size limit.

 

54 minutes ago, Iamattamai said:

A spritesheet is just about loading mostly, right? Is there any reduced processing overhead?

 

Loading is one of many benefits.

https://www.codeandweb.com/texturepacker

 

54 minutes ago, Iamattamai said:

I was hoping there might be a way to 'overlap' the reveal/hide just very slightly to reduce any momentary delay as one suggestion.

 

An overlap isn't needed. Showing and hiding will happen in the same frame if done correctly.

 

Here are a couple threads about sprite sheet animations:

 

 

 

 

 

  • Like 4

Share this post


Link to post
Share on other sites

Thank you OSUBlake for your patience.

You are helping me understand as well as make the fix.

Also much appreciate the links.

The 'design requirement' I mentioned is that the final solution be a single, self-contained, email-able file capable of offline function.

I'm not aware of another way to do it without base64, but I'm all ears.

I've tried the image loader link Zach suggested above and it verifies that the images are loaded but it doesn't fix the flicker.

I will attempt to build and test the large spritesheet these images will make soon, not sure what kind of size limitations might arise.

Worst case, the flicker isn't a show-stopper, just disappointing.

Share this post


Link to post
Share on other sites
31 minutes ago, Iamattamai said:

The 'design requirement' I mentioned is that the final solution be a single, self-contained, email-able file capable of offline function.

I'm not aware of another way to do it without base64, but I'm all ears.

 

So everything has to be inside in a html file? That's seems like a rather odd choice, but okay, I guess base64 might be your only option.

 

That said, I don't see any flicker on the demo you linked to here. Where are exactly do you see flicker? And in what browser and operating system?

  • Like 2

Share this post


Link to post
Share on other sites

Yep. Odd it may seem, but I won't bore you with a long story.

Flicker was occurring in IE, Edge, Chrome, and Safari - more pronounced as the files got bigger (more images).

I am developing on an i10 with 64 gig RAM - less pronounced on it, more so on an iPhone for instance.

In the end I just decided to go with setTimeouts and plain old JS - no more flicker.

My own suspicion is that it had to do with the processor skipping a beat to tend to something else now and then - I can't prove it and there was no discernable pattern.

Anyway, this works fine all things considered for this particular application.

Thank you for all your help and follow-up.

  • Like 1

Share this post


Link to post
Share on other sites

 

4 hours ago, Iamattamai said:

My own suspicion is that it had to do with the processor skipping a beat to tend to something else now and then

 

I'm not so sure.

 

I'm experiencing the same issue in a PNG sequence that runs in an Electron app that loads images locally and won't run until all images have officially loaded. I'm not using base64 images either. The images are transparent PNG files (created from an MOV file) ranging in size from 8K to 276K so not huge files.

 

I created a simple codepen that shows the same animation that hiccups in the app but seems to work fine in Chrome...

See the Pen LoQqyO by swampthang (@swampthang) on CodePen

 

In Chromium 69, the first time I ran the animation, I did notice a flicker right at the end. Also, if you don't play the animation initially, but just step through the frames, you'll more often see a misfire. Here's the thing though...

 

In the app, once a flicker happens it seems to 'stick' to the animation because I can step through the animation one frame at a time and when I get to that point, the image visibility remains 'hidden'. So it seems like whatever causes it to skip that frame gets "remembered" by the timeline. I wondered if the _gs objects that get attached to elements sometimes get cached and work both ways.

 

I'm probably making no sense - just trying to figure out what's up. I'll look in to creating a sprite but can't go to that at this point. Any insight into what might be happening would be greatly appreciated.

Share this post


Link to post
Share on other sites

Anybody else see flickering?

 

I seriously doubt this related to GSAP. Most likely a browser rendering issue. 

 

I bet you wouldn't see any problems using canvas.

 

See the Pen vpEQzY by osublake (@osublake) on CodePen

 

 

 

  • Like 3

Share this post


Link to post
Share on other sites
Just now, OSUblake said:

Anybody else see flickering?

 

Try reloading the page and then begin stepping through the animation without actually playing it.

Share this post


Link to post
Share on other sites

If you inspect the page and use the step button, it seems like I might not be calculating the frames correctly. Could that have something to do with it? Every once in awhile I see 2 visible images trigger at the same time or 2 hidden images trigger at the same time.

Share this post


Link to post
Share on other sites

That's what it looks like. Sometimes all of the images are hidden.

 

Maybe try doing that without using stagger.

  • Like 1

Share this post


Link to post
Share on other sites

Here's what I've learned in the past hour as regards my own experience...

I moved from stagger to straight JS as stated - flicker completely gone in Chrome and Edge on dev computer.

Moved to less powerful, smaller RAM work computer, all good.

Now I go do some miscellaneous work on work computer.

Return to app and run it again and flicker - here's my guess:

  - I am loading a large cache of images into RAM

  - That is all fine and good while the app remains the active page

  - Start doing some other work and the OS takes cache back - perhaps pushes some of that to disk.

  - Return to app and some images need to reload causing momentary flicker in doing so

I will try reloading just prior to triggering a replay and see if that fixes it.

Share this post


Link to post
Share on other sites
4 hours ago, Iamattamai said:

In the end I just decided to go with setTimeouts and plain old JS - no more flicker.

 

Using setTimeout will cause issues, especially if you leave the page and go do other work on your computer.

  • Like 2

Share this post


Link to post
Share on other sites
4 hours ago, Iamattamai said:

In the end I just decided to go with setTimeouts and plain old JS - no more flicker.

 

OSUBlake is right regarding setTimeout. Take a look at the last codepen i posted above and see if that might help. It's proving to be much more reliable.

  • Like 2

Share this post


Link to post
Share on other sites

This was actually quite interesting. I noticed that in @swampthang's first demo, it always broke on the 21st time I hit "next" which corresponded to exactly 0.7 seconds into the timeline. Hmm...

 

The way GSAP distributes the animations in the staggerTo() is by figuring out the total amount of time to distribute among the staggers (in this case it's the individual "stagger" amount, 1 / 30, multiplied by 76 because you've got 77 elements and the first one starts at 0, so there are 76 staggers...thus the total amount is 76 * 0.03333333333 = 2.5333333333333), then distributes that accordingly. Thus the math for the 21st one would look like:

2.5333333333333333 * (21 / 76); //0.7000000000000001

 

Kinda weird, right? Technically it should be 0.7 but due to the way floating point math works in computers, it's 0.7000000000000001. 

 

So if we have a tween placed at a time of 0.7000000000000001 and you put the playhead at 0.7, it's BEFORE that tween, hence the visibility doesn't get set to "visible". Your staggers that control setting visibility to "hidden" were offset by a whole frame, thus the rounding for those hits one set later, therefore you get these TINY slivers of time (like literally 0.0000000000001, and only in very particular/rare cases) where there's a gap. 

 

I wouldn't call it a "bug" in GSAP, but an interesting anomaly in extremely rare cases like this. I think I can work around it by doing some rounding under the hood for all the values. Here's a preview of the next release (uncompressed) that has the rounding in place: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/TweenMax-latest-beta.js

 

If you had chosen a different value for your "frame" that doesn't trip the floating point issues, like 1/32 instead of 1/30, you wouldn't see any of this. 

 

Does that make any sense? 

  • Like 4

Share this post


Link to post
Share on other sites

 

4 hours ago, GreenSock said:

Kinda weird, right? Technically it should be 0.7 but due to the way floating point math works in computers, it's 0.7000000000000001. 

 

Makes complete sense. I went ahead and changed the app to use a sequence of show/hide set pairs and it's working great.

 

Thanks for the beta link, the thorough explanation of what's going on here and once again - for an awesome library!

  • Like 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.