Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

First image in sequence isn't visible after loading #11

pisi opened this issue Dec 16, 2010 · 6 comments

First image in sequence isn't visible after loading #11

pisi opened this issue Dec 16, 2010 · 6 comments


Copy link

pisi commented Dec 16, 2010

Two users independently reported a unpleasant behavior of new image sequence feature in 1.1. When frames are being loaded, the very first one isn't displayed when loading is finished.

Please vote for this issue if it bugs you too!

Copy link

Tornth commented Jan 10, 2011

The very first image of mine also disappear. Can you suggest the workaroumd?

Copy link

Witti commented Jan 13, 2011

After all images are loaded the first image src is replaced with this string "gif;base64,R0lGODlhCAAIAIAAAAAAAAAAACH5BAEAAAAALAAAAAAIAAgAAAIHhI+py+1dAAA7" so the first image can't be displayed.

Remove line no 322 ("t.attr({ src: transparent }).trigger('loaded');")

Copy link

DaveGorski commented Jan 19, 2011

removing line 322 breaks the plugin for sprite based reels.

if(opt.images.length == 0){
    t.attr({ src: transparent }).trigger('loaded');

this will work in both cases

Copy link
Owner Author

pisi commented Jan 19, 2011

Dave! Guys!

I've immediatelly tested out your suggested method and it indeed works. Not for 100% because the loaded event trigger is an important one and must be triggered. But pretty pretty close!

I've adapted your solution in a branch gorski-method and that works just perfect!

Then, however, I've rooted down the stink bit deeper. I realized the reason was that the initial fractionChange event for default initial frame was being dropped as not-changed. Modified dropping condition is another solution for this fix and this one will probably make it into patch release 1.1.1.

Till then the cleanest solution is condition modification in the zero-fraction-fix branch.

Both branches include a test case.

Thank you very much, guys for practically solving this instead of me. Very much appreciated!

Copy link

Archivist-zz commented Mar 15, 2011

Oh, I apologize, I made a new post about this issue, but didn't see this here.

I hope 1.1.1 can be released soon!

Copy link
Owner Author

pisi commented Mar 20, 2011


I just released a patch version 1.1.1, which has a built-in cure for this issue along with test case assuring it won't re-emerge.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

5 participants