iOS Safari Memory Usage with "-Webkit-Transform"

iOS Safari memory usage with -webkit-transform

It crashes because the height of all hardware accelerated items is 257,025px in your example. In my tests it appeared that mobile-safari can handle about 20,000px in height before it crashes.

The hardware-acceleration is awesome but don't abuse it by using it for everything.

To help debug it through you will need to run Safari on Mac from the terminal with the following keys:

$> export CA_COLOR_OPAQUE=1 
$> export CA_LOG_MEMORY_USAGE=1
$> /Applications/Safari.app/Contents/MacOS/Safari

CA_COLOR_OPAQUE shows which elements are accelerated.CA_LOG_MEMORY_USAGE shows us how much memory is used for rendering.

Have a look at the following links for details:

• http://www.html5rocks.com/en/mobile/optimization-and-performance/
• http://engineering.linkedin.com/linkedin-ipad-5-techniques-smooth-infinite-scrolling-html5

IOS Safari transition transform not working

Old versions of iOS Safari support only vendor-prefixed properties and values for transition and transform, so you should use -webkit-transition: -webkit-transform instead -webkit-transition: transform:

JSFiddle

$('button').on('click', function() {

    $('.mydiv').toggleClass('added-class');

});

.mydiv {

    display: inline-block;

    width: 100px;

    height: 50px;

    background-color: red;

    -webkit-transform: translateY(0);

    -moz-transform: translateY(0);

    -ms-transform: translateY(0);

    -o-transform: translateY(0);

    transform: translateY(0);

    -webkit-transition: -webkit-transform 0.6s ease-out;

    -moz-transition: transform 0.6s ease-out;

    -o-transition: transform 0.6s ease-out;

    transition: transform 0.6s ease-out;

}

.added-class {

    -webkit-transform: translateY(100%);

    -moz-transform: translateY(100%);

    -ms-transform: translateY(100%);

    -o-transform: translateY(100%);

    transform: translateY(100%);

}

<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>

<div class="mydiv"></div>

<button type="button">Toggle class</button>

webkit-transform: scale breaks down when zoomed in on iOS

Here's the result of my extensive investigation before I gave up.

There are two major problems involved in applying transform: scale to content inside iframes on iOS. The first was what I pointed out in the original question, that content starts to drift away from it's specified location on the page if you are using fixed position elements. It works up to a point that seems to be based on the original size of the element, the scale factor, and presumably the viewport width. In my tests a large element might scale and position perfectly when scaled at any factor greater than 0.85. A small element might be positioned perfectly so long as the scale factor is at least >3.5. It seems almost random, so I didn't bother determining what the exact point was.

I didn't try this on relatively positioned elements, but I'm assuming they function similar to fixed position elements.

There is a rather kludgy workaround for this involving using absolutely positioned elements anchored to the bottom of the page using scroll offsets and innerHeight. i.e.:

container.css('top', (document.body.scrollTop + window.innerHeight - container.height()) + 'px');
container.css('left', document.body.scrollLeft);

And updating this on every drag, transform, pinch, resize, etc. There is some weirdness involved with this method (iOS doesn't update scroll offsets until after a drag has completely stopped) but it's workable if you absolutely had to do it.

However, even though that's a possibility, when you scale content inside iframes on iOS, if you have ANY anchor tags (or other elements that need to be clicked on), the clickable area stays unscaled. If you have an image in inside an anchor tag that's 200x100 and you scale it 2x, the image will be twice as big, but the anchor will only respond to the first 200x100. Using the iOS simulator, if you double click on an image outside the clickable area Safari is even helpful enough to darken the original bounds so you know where you could have clicked. It's pretty much a deal breaker if you want to display anything other than text/images that don't require clicking or other inputs. More information here:

CSS3 Transform scaling issue on IPad Safari

"-webkit-transform: scale(2)" doesn't affect click area of Facebook Like Button (on iPad)

Until Apple fixes these long standing bugs in mobile Safari, it seems that trying to scale iframe content using webkit-transform isn't a viable option unless you are only targeting Chrome.

Edit:

Demo of scaling issues here.

CSS3 property webkit-overflow-scrolling:touch ERROR

As @relluf pointed out, applying 3D transitions on the relative element fixes the bug. However, I investigated it a bit further and it seems that applying -webkit-transform: translateZ(0px) works too (this is what Google does on gmaps map container) and it does not need to be on the relatively positioned element, just the direct descendant of the scrollable element.

So if you don't want to manually keep a list of all the places where the fix is needed, you just might do:

element {
    -webkit-overflow-scrolling: touch;
}

element > * {
    -webkit-transform: translateZ(0px);
}

How do you tweak -webkit- prefixed CSS properties in jQuery?

$(this).css({
    '-webkit-transform':'rotate(180deg)',
    '-moz-transform': 'rotate(180deg)',
    '-o-transform': 'rotate(180deg)',
    '-ms-transform': 'rotate(180deg)'
});

---

Related Topics