Velocity kick only after all images are loaded #142

Closed
albell opened this Issue Aug 17, 2012 · 6 comments

Comments

Projects
None yet
2 participants
@albell

albell commented Aug 17, 2012

I'm using the new velocity option to give my objects an initial 360 spin. I've fiddled with the velocity and brake numbers so that each object goes for a perfect 360 when the page initially loads. (This is a great UI feature, because it indicates the functionality of the plug-in, without going on and on in a blinking, annoying way.) Basically, it's awesome. You can see the working page here:

http://bit.ly/Psprn8

It works nicely, especially in Webkit. Here's the basic idea: when the user clicks a new vase thumbnail to load it onto the "main stage":

a) all images of the class reel-cached get removed from the DOM.
b) the "main" img gets faded out
c) as a callback, the img then gets "unreeled"
d) the image's src gets swapped out with a new src
e) the new image gets faded back in, and
f) as a callback, reel is called on the new img.

Once all the images have all been cached then the transitions between the vases are all fairly smooth. The big problem, however, is that the initial velocity is getting kicked off before the "loading" is complete. Chrome is fast enough that this isn't such a problem, but it hurts to watch this in Firefox. My "complete rotation" in chrome turns into some weird jitter that doesn't fully complete. It's slightly different every time I clear the cache and reload. Ach!

It's clear to me that the preloader progress bar refers not to the images being in the browser cache (the conventional meaning of the word), but to the actual imgs having been loaded into the DOM with display: none. That makes sense.

But it's visually weird that my blue preloader box seems to be effectively synched with the twirl of the vase. What I want is to have the preloader complete, and then twirl the vase, fluidly. I realize you've put a ton of thought into performance, and not holding up basic functionality on slower machines, but I'd rather make the user wait a little and show them something reasonably smooth than kick off an animation that just isn't ready. Is there some happy compromise solution here?

P.S. While I'm here (and you're here, dear reader) there is another weird problem in Firefox, too, that is not really a problem with the plugin but I thought I'd ask anyways :) At step (e) above, when the new image is fading in, for a moment it's actually the old image, which then abruptly gets swapped out. It's weird. I'm trying to be all smooth with the transitions in my jQuery, and I think I'm using callbacks properly, but Gecko is effectively messing with my event sequence. Any idea how to work around this?

Thanks so much!

@ghost ghost assigned pisi Aug 17, 2012

@pisi

This comment has been minimized.

Show comment
Hide comment
@pisi

pisi Aug 19, 2012

Owner

What a post! And a good point too. I agree with you, that the initial velocity kick should be carried out AFTER all the necessary image resources are at hand or else it doesn't look good enough.

Owner

pisi commented Aug 19, 2012

What a post! And a good point too. I agree with you, that the initial velocity kick should be carried out AFTER all the necessary image resources are at hand or else it doesn't look good enough.

pisi added a commit that referenced this issue Aug 19, 2012

@pisi

This comment has been minimized.

Show comment
Hide comment
@pisi

pisi Aug 19, 2012

Owner

I implemented the change in separate post-loaded-velocity branch for you to use and for future merge into 1.2.1 release. It now does the velocity kick as a callback to loaded event. I also added a flag to disable the kick if the user already interacted with the Reel during loading.

Please give it a try and let me know your thoughts.

Also you might want to check out opening animation feature, which serves the same purpose (functionality preview) but in a different way ;)

Owner

pisi commented Aug 19, 2012

I implemented the change in separate post-loaded-velocity branch for you to use and for future merge into 1.2.1 release. It now does the velocity kick as a callback to loaded event. I also added a flag to disable the kick if the user already interacted with the Reel during loading.

Please give it a try and let me know your thoughts.

Also you might want to check out opening animation feature, which serves the same purpose (functionality preview) but in a different way ;)

@albell

This comment has been minimized.

Show comment
Hide comment
@albell

albell Aug 20, 2012

Thanks for the fix. Reading through some other posts, I wound up figuring this out using the data option and the loaded event, which also works:

$(this).reel({
    brake: myValue,
    });
$(this).on('loaded', function(){
    $(this).data('velocity', imageVelocity);
});

albell commented Aug 20, 2012

Thanks for the fix. Reading through some other posts, I wound up figuring this out using the data option and the loaded event, which also works:

$(this).reel({
    brake: myValue,
    });
$(this).on('loaded', function(){
    $(this).data('velocity', imageVelocity);
});
@pisi

This comment has been minimized.

Show comment
Hide comment
@pisi

pisi Aug 20, 2012

Owner

Also an option! ;) Thanks for sharing with others.

Owner

pisi commented Aug 20, 2012

Also an option! ;) Thanks for sharing with others.

@pisi pisi closed this Aug 20, 2012

@pisi

This comment has been minimized.

Show comment
Hide comment
@pisi

pisi Oct 10, 2012

Owner

Just landed in the development branch, the sure way to master ;).

Owner

pisi commented Oct 10, 2012

Just landed in the development branch, the sure way to master ;).

@pisi pisi reopened this Oct 10, 2012

@pisi pisi closed this Oct 11, 2012

pisi added a commit that referenced this issue Feb 23, 2013

Reel 1.2.1
========

* new exciting multi-row stitched panorama possibility
* full compatibility with jQuery 1.9.x and 2.0 beta
* one less dependency (disableTextSelect)
* fixed page scrolling on touch devices
* maximal throw velocity via `throwable`
* image assets folder
* fixed image sequence allowing for odd starting points

Includes fixes for issues #129, #140, #174, #175, #142, #146, #144, #129, #172
@pisi

This comment has been minimized.

Show comment
Hide comment
@pisi

pisi Feb 23, 2013

Owner

Merged into master and included in today's version 1.2.1 release.

Owner

pisi commented Feb 23, 2013

Merged into master and included in today's version 1.2.1 release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment