HTML5 салфетки.переходы JS css3; закадровый рендеринг и кэширование элементов страницы

Я создаю журнал HTML5 для планшетов и настольных компьютеров с использованием swipe.js (http://swipejs.com).

Все вроде бы работает нормально,на одной HTML-странице Я установил рядом друг с другом полноэкранные элементы списка. Весь журнал построен в одном статическом html-файле. Я могу скользить по страницам, проводя пальцем по планшетам и используя кнопки для настольной версии (рассмотрим пример на салфетке.Домашняя страница js, но затем с полноэкранными слайдами).

Страницы расположены рядом друг с другом и имеют размеры экрана.

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

Размах.переходы js выполняются с помощью css3, используя функцию translate3d() css. В этом случае используется аппаратный рендеринг.

На рабочем столе (Chrome, Safari, FF), iPad1 и (еще лучше) iPad2 это имеет желаемый эффект, который я искал; плавные переходы. Отлично! Однако на iPad3 страницы, по-видимому, отображаются "медленно" при первом вводе (при переходе). Даже без установки фоновые изображения (только цвет), "рендеринг" переходной страницы считается немного "медленным"; страница строится "мерцающими" блоками.

Предположение : Я предполагаю (после прочтения темы), что это происходит потому, что браузер только отображает элементы, которые находятся на экране, и будет кэшировать пролистанные страницы только на некоторое время, очищая кэш после этого для управления управлением памятью.

Мой вопрос : есть ли способ контролировать закадровый рендеринг и кэширование, чтобы я мог заставить (предварительно) рендерить элементы страницы i-1, i+1 (и очистить кэш для всех других элементов страницы), чтобы ускорить рендеринг перехода?

Примечание: в нескольких разделах StackOverflow упоминается "мерцание" переходов css3. Я реализовал предложенные CSS трюки, но не решу свой случай. 

-webkit-backface-visibility: hidden;
-webkit-transform:translate3d(0,0,0);
2 12
html5 css-transitions rendering browser-cache

2 ответа:

В итоге решением стал Хак Swipejs, в который я добавил метод ' hideOthers ()', установив видимость стиля на 'hidden', который выгружает страницы из аппаратной памяти: 

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';
          }
      }
   }
}

..и добавил триггер ниже в качестве последней строки в методе 'slide ()' 

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

Только translate3d был необходим для включения аппаратного ускорения (как упоминалось в моем вопросе выше): 

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

Вы можете найти результат (включая iScroll для вертикальной прокрутки) здесь .

4

Что касается реквизитов webkit backface / translate3d, используемых для запуска аппаратного ускорения, я читал, что в iOS 6+ они работают не совсем так, как в предыдущих версиях, и (что более важно), что аппаратное ускорение должно применяться не только к анимируемому элементу, но и к любому элементу, который он перекрывает/перекрывает его.

Ссылка (немного): http://indiegamr.com/ios6-html-hardware-acceleration-changes-and-how-to-fix-them/

К честно говоря, это довольно анекдотический случай, я сам не смог исправить свою собственную проблему мерцания - из - за сжатых сроков-но это может быть точкой в правильном направлении.

0