iFrame plays HTML Canvas animations slower in Safari

[Kieren Smith]

Hey All,

Does anyone else experience slow playback when loading HTML canvas animations into iFrames within Safari? e.g. a banner ad?

I have tested this within Safari on my computer and it only seems to be happening on my own computer... And It doesn't happen in Chrome or firefox.

And the weird thing is when I click the animation in safari. The animation then speeds up and plays at normal speed. I'm wondering if there is some sort of idle thing happening within my safari that plays banners at a slower speed on purpose until I interact with it.

This doesn't seem to happen on other machines I've tested on. And I've created banner ads using GWD as well, and those play at a normal speed within iFrames.

If I open the index file in safari it plays normally, it's just when it's being loaded into iFrames.

Anyone able to shed some light on this weird anomaly?

Here is a link to the banner example loaded in an iframe: scrn Dashboard - (just pop your name and email address in to view the banner)

*Update: I have also tested on iphone safari and chrome. Both chrome and safari are playing the Adobe CC banners slower until they have been interacted with. As soon as you touch the banner it speeds up in both Chrome and Safari on iOS devices.

Message was edited by: Kieren Smith

[DustinKerstein]

I have the exact same issue on Mobile Safari and it's really causing some headaches. Have you found any workarounds yet?

[Kieren Smith]

Unfortunately I haven’t found a work around.

I’ve been making banners for ages and sending them out and I’m worried they’ll be playing slower for people using safari or iOS devices. It’s not a huge deal, they just don’t look as smooth. Also it makes me wonder what happens with animations that can only be 30seconds in length. With the animations playing slower they’ll be going over 30seconds...

I tested on a friends computer and his was playing slow as well in safari. In Chrome it was playing normal speed.

Cheers,

Kieren

0211616488

www.incognitodesign.co.nz

*Please excuse any autocorrect fails, this was sent from my mobile.

[DustinKerstein]

Hey Kieren,

I just wrote a very hacky workaround for my use-case involving a forced modal (ie. a play button) that requires a quick (<100ms tap) to hide. This single quick tap (it must be very short) gets things running at full speed. Not sure if you'd be able to do something similar, but that's all I've been able to figure out.

-Dustin

[Kieren Smith]

Hey Dustin

Are you able to share the hack with me please so I can do a quick test?

Cheers

Kieren.

Cheers

K.

Kieren Smith

Director - Incognito Design & Media

M: 021 1616 488

E: kieren@incognitodesign.co.nz

W: incognitodesign.co.nz <http://www.incognitodesign.co.nz>

Remember: I don't work on Fridays.

On 12 January 2018 at 09:09, Dustin Kerstein <forums_noreply@adobe.com>

[DustinKerstein]

It really is just me adding a play button overlay and then detecting the touchStart / touchEnd events. If the time between those events < 100ms then I hide the play button. That way I force the user to click into the iFrame. It's more of a user behavior hack than an actual code workaround. Does that make sense?

[Kieren Smith]

Yea that makes sense.

I don’t know if it’s something that would work for me. Because the animations are banner ads, people might not be interacting with them at all so I can only assume they will be playing slowly from the beginning, and if they do click on the banner, it will speed up, but that doesn’t really matter because the click will take them to a different website anyway.

So I really don’t know what to do and how to get the banner to be playing at the correct frame rate from the beginning within safari.

Maybe I’ll have to switch to google web designer. That doesn’t have any frame rate issues, but it’s an absolute dog to work with compared to animate.

Cheers,

Kieren

[TheOtherStef]

Hey Kieren, just discovered this too, exactly as you've described.

My DoubleClick previews run like a dog in Safari and iOS until interacted with, like a right click even.

Locally in Safari it runs fine.

I'm around 80% sure I've tested mobile banners on my phone before and would've noticed the slow playback. Reckon it might be a recent bug introduced by Safari?

[Kieren Smith]

I think it may be! I never experienced it until maybe about 8ish months ago... And there have been several safari updates in that time.

I just don't know who to contact about it all... Noone listens and it is such an obscure issue...

[TheOtherStef]

I've just submitted bug reports for both Safari and Animate CC.

Keep your fingers crossed.

[Kieren Smith]

Good stuff! let's get them from all sides, I was just chatting to an adobe empolee and explaind it to him. He has passed it all on to his superiors to follow up. they will get back to me within 48hrs. I'll let you know.

[TheOtherStef]

One thing I've been trying (without luck so far), is to simulate click events on the canvas. Might need to be targeting the parent elements/iFrame?

I figure if interaction returns the framerate to normal then maybe we can do that via code.

Another thing someone suggested was trying to set the focus of the banner.

Any .js gurus have any further ideas?

[Preran]

Hi everyone, the team is investigating this issue. I will keep you updated as soon as I have something new to say.

[Kieren Smith · Accepted solution]

Thanks Preran,

I was in touch with one of the testers recently and they were trying out a bunch of stuff. The issue is in safari (obviously), And so apple has been notified about this abnormality...

This is the comment I got from the adobe tester:
"it is a dependency issue where we will require assistance from Apple team to resolve this bug."

So chances are well not be seeing any fixes from apple any time soon.

Might have to switch to google web designer for the time being which has it's issues as well...

[AnthonyS82]

Hi Preran,

Has there been any update regarding this issue? we've experienced the same issue with one of our banner creatives playing on IOS devices using Safari. The creative was developed using Animate CC.

Thanks,

Anthony

[marcusb63836720]

I'm also waiting for an answer to this problem, in the meantime I'll be handcoding my banner ads with GSAP.

[ClayUUID]

marcusb63836720  wrote

I'm also waiting for an answer to this problem, in the meantime I'll be handcoding my banner ads with GSAP.

It sounds like Safari is intentionally throttling iframe content until it's interacted with. If so, it wouldn't matter whether you're using GSAP or Animate. Does GSAP-driven content not experience the slowdown issue when hosted in an iframe?

[Kieren Smith]

In my experience banners crated in Google w b designer aren’t throttled in iframes on safari. Just HTML canvas banners.

Cheers,

Kieren

0211616488

www.incognitodesign.co.nz

*Please excuse any autocorrect fails, this was sent from my mobile.

[davi-t]

Safari began throttling RAF in cross-origin iframes for non-interacted-with content a while back. Creating a fake user interaction won't work either. I ran into this issue going through QA on some Adobe Animate created banners. Seems as though Safari will throttle RAF to half of the request (so if you're using frame-based animation like Animate's timeline, expect to see if slow by half. For example, a 30FPS animation will play back as if it is 15FPS).

My workaround was to use AdHelper (the lil' library for ads from gskinner for Animate CC). So I'm checking if the ad is in an iframe, then if the browser is Safari, and then using AdHelper's "timeSync" to sync to the actual frame duration. It gets a tad bit choppy because it's the lower FPS with less interpolated frames, but at least it's syncing with the actual durations that they were meant to be.

I have code but it won't make sense for most folks since it goes with my ad templates and lots of other code, but here's what it might be converted to. You may want to QA portions of this. Obviously call this function somewhere in your own code and make sure you have the AdHelper library loaded.

function checkIfThrottlingRAF() {

    if(window.self !== window.top && !!navigator.userAgent.toLowerCase().match(/version\/[\d\.]+.*safari/)) {

        adHelper = new createjs.AdHelper(stage).timeSync();

    }

}

[AnthonyS82]

Hi Davi,

Quick question, have you been able to make AdHelper work within an Animate CC 2018 or 2019 template? We're having issues with the latest Adobe software and getting the AdHelper to work correctly. Wondering if you're experiencing the same issue? our 2016 / 2017 templates work fine with AdHelper.

Cheers,

Anthony

[robetmanski]

I'm having the same issue - I can't get it to work with Animate CC 2019. Any luck from anyone?

[robetmanski]

Update - I got AdHelper to work with Animate CC 2019. Just add this at the bottom of the handleComplete() function (I added it to a custom template I created):

var ad = new createjs.AdHelper(stage).timeSync(lib.properties.fps);

TimeSync only works with MovieClips, so in order to get this to work you need to do one of two things: if developing on the root timeline make every element a MovieClip, or create one MovieClip and place it on the root timeline then do all of your animating inside of that. I went with the latter and also increased my FPS to 60 so if it does drop it's interpolating 30 fps into 60 and not 15 into 30 (which looks really choppy).

Here's a link to their White Paper: https://createjs.com/html5ads/#TimeSync

[Kieren Smith]

SO it has been over a year and still nothing has changed. Still slow until interacted with. Does anyone else have any work arounds?

[DustinKerstein]

Also, note that a touch swiping action doesn't count. It has to be registered as a click. Mouse on Desktop Safari behaves differently. Even with a quick drag the iFrame considers it "interacted with" and runs at full speed. So the issue is only on mobile touch iOS devices. Does anyone have a link to a WebKit bug report about this issue? I don't want to create a dupe.

[stuart_hart1]

I've also been looking for a solution to this issue. It's significantly impacting the performance of our creatives and I've yet to find a decent solution that 'just works'. Everything I've tried so far has some sorta deal-breaking disadvantage.

If anyone's holding onto a solution, please PLEASE share it with the rest of us! It's been over a year and a half since this issue was raised in this thread alone; it's clearly not going to get fixed by Apple or Adobe or whoever's responsible any time soon.