HTML5 swipe.js css3 transitions; offscreen rendering and caching of page elements

Question

I am building a HTML5 magazine for tablets and desktops with use of swipe.js (http://swipejs.com).

Everything seems to work fine, In one HTML page I have set next to each other fullscreen list elements. The whole magazine is build up in one static html file. I can slide through the pages by swiping on tablets, and by using buttons for the desktop version (consider the example on the swipe.js homepage, but then with fullscreen slides).

The pages are placed next to each other, and have the dimensions of the screen.

[ |0||1||2| .. |i-1||i||i+1| .. |n| ]

The swipe.js transitions are done with help of css3, using the translate3d() css function. In this case, hardware rendering is used.

On desktop (Chrome, Safari, FF), iPad1 and (even better on) iPad2 this has the desired effect I was looking for; smooth transitions. Perfect! However, on the iPad3, the pages seem to render 'slow' when entered (by transition) for the first time. Even without setting background images (just the color), the 'rendering' of the transitioned page is considered a little 'slow'; the page is build up by 'flickering' blocks.

Assumption: My assumption is (after reading into the subject), that this is because the browser only renders the elements that are in-screen, and will cache the swiped pages only for a while, cleaning the cache afterwards to control memory management.

My question: Is there a way to control the offscreen rendering and caching, so that I can force (pre) render page elements i-1, i+1 (and flush the cache for all other page elements), to speed up my transition rendering?

Note: In several topics on StackOverflow, 'flickering' of css3 transitions is mentioned. I have implemented the suggested CSS tricks but will not solve my case.

-webkit-backface-visibility: hidden;
-webkit-transform:translate3d(0,0,0);

Bumbledom

will stacking the pages with z-indexing help? – Duplessismornay

Please take a look at this link: jquerymobile.com/demos/1.2.0/docs/pages/page-cache.html. – Irkutsk

Late comments: @Tim: stacking won't work, the pages are still in memory. – Bumbledom

@Esteban: It seems to be a similar approach (based on DOM). Removing from the DOM will als remove from memory. You might have to reload the whole DOM part again. – Bumbledom

Answer 1

In the end the solution was a hack of Swipejs in which I added a method 'hideOthers()', setting the style visibility to 'hidden', which unloads the pages from hardware memory:

hideOthers: function(index) {
  var i = 0;
  var el;

  for( i in this.slides ) {
      el = this.slides[i];
      if ( el.tagName == 'LI' ) {
          // Show pages i-1, i and i+1
          if ( parseInt(i) == index
             || (parseInt(i) + 1) == index
             || (parseInt(i) - 1) == index
          ) {
              el.style.visibility = 'visible';
          }
          else {
              el.style.visibility = 'hidden';
          }
      }
   }
}

..and added the trigger below as last line in the 'slide()' method

// unload list elements from memory
var self = this;
setTimeout( function() { self.hideOthers(index); }, 100 );

Only the translate3d was needed to toggle the hardware acceleration on (as mentioned in my question above):

-webkit-transform:translate3d(0,0,0);

You can find the result (including iScroll for vertical scrolling) here.

Bumbledom

Hi, i know this is an old post but i have exactly the same question of you. I'm trying to understand by default how many slides swipe.js caches and i found you method to precsche the next and previous slide really interesting. But i had a look to your link and on my browser chrome is massive flickering, while on iphone5 it seems to heavy and is hard to swipe, there is lag on sliding event. Is that your end version with all the fixes? Thanks – Disrobe

Yes, this was the end result. I can't reproduce that behaviour - tested on several operating systems and browsers. The system can be optimised a lot (work in progress for other project). It is not the amount of slides that count; what counts is the area(!) that is loaded in memory (by the hardware acceleration). So in theory one page can already be too heavy for a mobile device. – Bumbledom

Answer 2

in regards to the webkit backface/translate3d props used to trigger hardware acceleration, I've read that in iOS 6+ these don't work quite the same as in previous versions, and (more importantly) that hardware acceleration needs to be applied not only on the element that is being animated, but also on any element that it is overlapping/overlaps it.

reference (not much): http://indiegamr.com/ios6-html-hardware-acceleration-changes-and-how-to-fix-them/

To be fair this is fairly anecdotal, I was myself unable to fix my own flickering issue - due to tight deadlines - but this might be a point in the right direction.

Witherite