12

I'm building a site that does parallax scrolling with requestAnimationFrame. There are multiple sections, each with a full-sized background image and some mid- and foreground images as well. I've managed to get this animating relatively smoothly via requestAnimationFrame, but there are still occasional jitters in the animation.

By watching Chrome's timeline in Frame mode, I can see that the processes that are causing the "jank" are labeled "Image Decode." Furthermore, the jank does not recur once the animation has been completed once.

It seems that most browsers are now deferring the decoding of images not yet in view. Is there a way I can pre-decode (not just preload) the images without them being visible to the user?

modernserf
  • 300
  • 1
  • 14
  • Are these jitters possible because the size of the element is not yet known? Do you have a link with an example? – Brad Nov 09 '12 at 14:59
  • 1
    I see... as I scroll, the scrolling stops for a brief moment while the images decode. That is the problem you are referring to, yes? have you tried showing all of your images within a div on the top? They don't have to be visible... set a z-index or even show a 1x1 div, if necessary. – Brad Nov 09 '12 at 15:01
  • FYI--I get animation issues even after going through once (Win &, Firefox 16). – ScottS Nov 09 '12 at 20:55
  • i've tried showing all the images, even visibly, and it doesn't seem to affect performance either way -- I'm still seeing the "image decode" in the inspector and the jank in the animation. – modernserf Nov 09 '12 at 21:48
  • 1
    Did you try the canvas element? – wukong Nov 10 '12 at 16:32
  • I think the jitters could be caused due to the combination of requestanimationframe and scrolling. Just as a test try overwriting requestanimationframe with window.requestAnimationFrame = function( callback ){ window.setTimeout(callback, 1000 / 60); }; – lostsource Nov 11 '12 at 09:37
  • FYI, that's hideously unresponsive (and IMNSHO hideous to look at too). You need to be able to cancel outstanding scrolls in one direction as soon as the user tries to scroll in the opposite direction. – Alnitak Nov 11 '12 at 09:53
  • @Alnitak not my design, bro. – modernserf Nov 13 '12 at 15:55

3 Answers3

1

The issue could be related to the images being scrolled out of/into view.

From http://creativejs.com/resources/requestanimationframe/

It has also been hinted that browsers could choose to optimize performace of requestAnimationFrame based on load, element visibility (being scrolled out of view) and battery status.

Also from the W3C draft

ISSUE-4 Do we want to allow an Element to be passed to requestAnimationFrame, so that animations affecting the given element are throttled or paused when scrolled out of view?

Make sure that you're not starting a requestAnimationFrame loop for each onscroll event as that may cause problems. This is described in detail in this separate post

Questions about Request Animation Frame

Community
  • 1
  • 1
lostsource
  • 21,070
  • 8
  • 66
  • 88
0

I solved this by eliminating the line that checks whether an element is onscreen or not, which was likely doing the same thing as the browser, only poorly.

modernserf
  • 300
  • 1
  • 14
0

You can pre decode images into an array

const img = new Image();
img.src = "bigImage.jpg";
img.decode().then(() => {
    images.push(img)
}).catch(() => {
    throw new Error('Could not load/decode big image.');
});

In the example the author requests to decode an image element. The decode implies a load, followed by the decode of the image. The call returns a promise, which, when fulfilled, ensures that the image can be appended to the DOM without causing a decoding delay on the next frame.

Dan Froberg
  • 168
  • 8