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

Prevent flickers for already loaded images. #325

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

nybblr
Copy link

@nybblr nybblr commented Apr 21, 2016

Large single-page apps, like Ember, will sometimes rerender the same element with the same image. This can cause lots of flickering with lazyload.

Also, an image reused throughout the page (say, an avatar) fades in every single time, which can make for a jumpy experience (esp. if a rerender is triggered).

Last, the start of the animation is hardwired to hide(), which unnecessarily causes page reflow issues even when the dimensions are known.

To fix this, settings.effect accepts a function, which defaults to a noop (preventing flickering for folks without any effect specified), and the effects are never run if the image is already cached. If settings.effect is a string, it gets converted to a function as before, so it should be backwards compatible.

For my specific use case, this lets me just use $el.css({opacity: 0}).animate({opacity: 1}); as my effect, which doesn't cause a page reflow or flicker.

Tested in Firefox and Chrome.

Easier to see relevant changes with the ?w=1 flag.

* In large SPAs where an image is reused throughout the page, lazyload
* has a tendency to "flicker" because of the unnecessary hide/show
* cycle. So first, check if an image is already loaded in the cache and
* disable any effects (including user specified ones). Otherwise, go on
* as before. As a side note, the `effect` API accepts an arbitrary
* function, so it's easier to build flicker-resistant animations in,
* say, Ember apps. However, a string is still accepted and just
* converted to a function.
@nybblr
Copy link
Author

nybblr commented Apr 21, 2016

Related, this closes #161

@pdougall1
Copy link

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants