Using phone, animation runs extremely badly when standalone, but perfectly fine when embedded in site??

[RoGuE_StreaK]

Wondering if a knowledgeable person can figure out why, on my oldish android phone, my GSAP animations run extremely poorly when viewed standalone, but when embedded within the destination website they run perfectly smoothly??  Not particularly an issue as everyone else sees it via the site itself, but I can't understand why it's happening when it's the exact same page.  Wanting to ensure you don't need the very latest phone to use the page smoothly, that any old device will work.

 

It's developed within Animate CC (2018) (I'm an old Flash developer), with pretty-much everything being dynamically driven by GSAP v3.6; I haven't checked the latest offering to see if I need to change things to upgrade to v3.11 like I did when moving from v2.  Over the years it's been heavily optimised and recoded, runs buttery smooth EXCEPT when I view it directly in a browser on my Moto G7 android.  Have tested different browsers with the same result, very bad when standalone, smooth as silk when embedded.  Runs fine standalone on my work iphone, and of course when viewed on a laptop etc.

 

Here's the direct version

https://baudalign.com/hp2023/board_selector_v233.html

 

And here's the embedded version, sitting in a div which resizes to suit the browser viewing window height/width

https://www.hpbodyboards.com/pages/visualise-your-custom

 

As I said, it's not a big deal as it works for practically everyone, but I'm just at a loss as to why the exact same page runs very differently depending on whether it's standalone or embedded!  So any help / thoughts / advice would be greatly appreciated.

[GreenSock]

Howdy, @RoGuE_StreaK! Nice to hear from a fellow "old Flash developer" 

 

I don't have a lot of time to dig into this, but I wasn't sure what you meant by "standalone" - are you just saying that the "good" one has extra elements surrounding it, like a menu, footer, etc.? So it's exactly the same animated HTML file that's loaded in an <iframe> and somehow doing that makes it perform much better? 

 

The only thing that came to mind initially for me was the device throttling requestAnimationFrame() or something like that. For example, iOS devices only ran iframe content at 30fps instead of 60fps (in terms of requestAnimationFrame()) UNTIL the user taps/interacts with that iframe. It has absolutely nothing to do with GSAP. It's a device thing. And GSAP of course runs on top of a requestAnimationFrame() loop (and falls back to setTimeout()). What's odd here (if I understand you correctly) is that it's the OPPOSITE of that, right? The <iframe> stuff is animating smoothly, and when the exact same HTML page from that <iframe> is loaded directly in the browser, it performs much worse? Is one of them scaled differently than the other? For example, I wonder if you've got various assets that are at certain pixel dimensions and they fit perfectly into the <iframe> so that there's no scaling necessary, but when you load OUTSIDE of the <iframe> (directly), the browser has to do a bunch of scaling to your raster images to fill the screen with the canvas? Again, I'm just taking shots in the dark. I'd make sure that when you're comparing them, they're at identical resolutions. And maybe check any settings for the <canvas> rendering, antialiasing, etc. 

[GreenSock]

Also, you should have nothing to worry about when upgrading from 3.6 to 3.11. You'll just get extra features and improvements/fixes. We're very careful not to shift the API around unless it's a major release (going from version 2.x to 3.x or 3.x to 4.x). 

[RoGuE_StreaK]

Hi Jack, yes the "good" version has the animated HTML page loaded into an iframe in a div, it's a Shopify site so was quite limited to what he could do, and this way made it easier for me to make updates and just send him a new link, especially with a spritesheet etc needing to be imported.  Most changeable settings like colours listed are dictated by external github files, so he can change stock without needing me to republish.

The majority of graphics are deliberately vector, with some PNG overlays for textures, and those would be scaled on my phone; but I'll see if I can get an exact div size from the "good" site when it displays on my phone, and create a test holding page for the "standalone" version so that element is exactly the same for testing.

For quite some time I was caching the dynamically coloured elements as bitmap and using easel to colour them, but in moving to v3 I finally figured out how to directly address the vector fills to tween or set their style values instead.  This did improve performance on low-end devices, as did compressing the overlay PNG spritesheet with tinypng (actually that was more load time reduction)

I didn't particularly think it was directly a GSAP issue as such, but thought perhaps someone here has come across the issue and/or know more about the various concerns that can impact how well animations perform.