Off-Topic: super weird Safari rendering bug

[katerlouis]

Sorry to bother you with this. If you find this inappropriate, please forgive me and just delete the topic.

I can't imagine the issue is related to GSAP.. but I can't imagine what else could cause this weird bug.

 

What am I talking about?

Please visit http://dumbo.design/airberlin in Safari – You'll see what I mean...

 

Issue occurs on the "work page"; the content isn't fully rendered... it looks super glitchy. 

When you highlight the page by marking text or pressing CMD+A everything in the viewport gets rendert correctly immediately.

Scroll a bit further and the same issue applies to the rest.

 

Does anyone have ever faced such an issue?

I'm really grasping for straws here, guys: I'd appreciate the slightest idea on what could cause this.

 

 

Thank you very much,

 

René 

[Jonathan]

To me this looks like all the assets aren't loaded yet before they are trying to animate. I only saw this on iOS (11.2.1) IPAD in Safari and Chrome.

• Have you tried to only trigger the tweens and timeline after the window is loaded and the DOM is ready?
  ( This way all images have been loaded into memory and the DOM tree is fully built before animating )

[katerlouis]

Thanks for your help!

 

I do $(document).ready() before the whole thing starts.

And the glitch seems to occur with normal text and background colors aswell. 

 

The setup for all pages is the same, so if you would be right about that, I guess the other pages would have the same issue, which they don't :'(

[Jonathan]

You might want to add $(window).bind("load")  within your $(document).ready(). Since the ready() event only deals with checking if the DOM is ready for the document tree node, and doesn't check for the window load event for the window tree node for images being fully loaded.

 

This way it checks for the window load event making sure all assets like images, links, stylesheets, fonts, etc.. are fully loaded, which is different than document ready() event for the DOM.

 

This way you can make sure its not a DOM ready along with window load event issue. As best practice i always do the following to make sure I only animate when DOM is ready and window is fully loaded, especially when i use image.

 

But even if this doesn't solve your problem its always best to only animate when everything is loaded so you get consistent loading of your project cross browser, especially when you are animating images..

 

jQuery way:

 

// wait until DOM is ready
$(document).ready(function(){
  
  // wait until window is loaded for all external assets like images, fonts, scripts, stylesheets, etc
  $(window).bind("load", function(){
    
    // custom animation code goes here
    
  });  
});

 

Even if the window is fully loaded before the ready() event, it will fire immediately when the ready event is fired. This way you ensure that both are fired in the right order due to server waiting times and other network shenanigans.

 

Or native vanilla JS way:

 

// wait until DOM is ready
document.addEventListener("DOMContentLoaded", function(event) {
  
  // wait until window is loaded for all external assets like images, fonts, scripts, stylesheets, etc
  window.addEventListener("load", function(event) {
  
      // custom animation code goes here    
    
  }, false);  
});

 

Happy Tweening

 

 

[katerlouis]

I found something!

 

* {
  -webkit-backface-visibility: hidden;
}

 

seems to eliminate atleast most glitches, but not all?

The page still lags horrendously. Again, only the /airberlin page is affected...

 

Can you confirm this on the updated version? 

I've tested multiple apple devices, and all have still the glitches to some degree...

[GreenSock]

Yeah, the way that page is built looks problematic to me (performance-wise). You've got some very large images (like a 2607x2607 SVG as well as several other PNGs and SVGs) that are shifting by over 4000 pixels (on my screen at least). SVGs are particularly bad for rendering performance, and it has nothing to do with GSAP. You've just got a ton of pixels that you're asking the browser to repaint on each tick. 

 

It's always best to minimize the area of change so that the "dirty pixels" are minimized and the browser can focus on the smallest areas possible. Think of drawing a rectangle around all the changed pixels (even off-screen in many cases) - that's what the browser has to figure out. Make that rectangle as small as possible. When you've got a 2607x2607 pixel SVG that's moving over 4000 pixels...that's just a ton of work. It's almost 7,000,000 pixels alone, plus the delta on each tick. 

 

You could also try swapping in a PNG for that SVG to see if Safari handles that any better, but I'm not sure it will. The tricky thing about SVGs is that they're resolution-independent, thus the browser must rasterize (calculate all the pixels) the artwork through math and they can't really be shoved over to the GPU for rendering. It's a CPU-heavy task. Again, none of this has anything to do with GSAP. 

[katerlouis]

Thank you very much, Jack!

In your statement you are mainly talking about the 3 hefty chpater intros with the mockups, I suppose?

 

1) Could performance alone cause the glitchy problem, which is still present in some places, the second chapter intro with the iPhone mockup, for instance?

 

2) Would it be possible to tell GSAP to lower the ticks for these three animations? Less fps would be better than this mess..

 

3) How comes Chrome and Firefox make it work so smoothly? Are there any known "Don't Do"s with animations in Safari? Maybe some css property which is known to f*** things up?

 

4) How would force3D effect performance in this situation? So far the 3 mockups get matrix() and not matrix3d()

[GreenSock]

16 minutes ago, kreativzirkel said:

1) Could performance alone cause the glitchy problem, which is still present in some places, the second chapter intro with the iPhone mockup, for instance?

Absolutely.

 

17 minutes ago, kreativzirkel said:

2) Would it be possible to tell GSAP to lower the ticks for these three animations? Less fps would be better than this mess..

You can tell GSAP to cap the FPS at whatever you want, whenever you want. 

 

TweenLite.ticker.fps(15); //caps at 15fps

 

Not sure that's the best solution, though. 

 

18 minutes ago, kreativzirkel said:

3) How comes Chrome and Firefox make it work so smoothly? Are there any known "Don't Do"s with animations in Safari? Maybe some css property which is known to f*** things up?

 

Each browser has its own quirks and strategies for "optimizing" the rendering pipeline. Chrome and Firefox may have an algorithm that's working better in your particular scenario. As far as "don't do ___ in Safari", the only thing I can think of right now is just related to animating SVG masks inside <defs>, as discussed here: 

 

22 minutes ago, kreativzirkel said:

4) How would force3D effect performance in this situation? So far the 3 mockups get matrix() and not matrix3d()

 

Probably won't help. You're welcome to set force3D:true on those tweens, but keep in mind that it won't help anything on SVG elements since there's no such thing as 3D in SVG and most browsers cannot GPU-accelerate SVGs. 

[katerlouis]

12 hours ago, GreenSock said:

You can tell GSAP to cap the FPS at whatever you want, whenever you want. 

 

TweenLite.ticker.fps(15); //caps at 15fps

 

 

I suppose you can't set ticker.fps() only for a few tweens, and let the rest play it the normal FPS?

[GreenSock]

You can set it whenever you want, sure. But if you're asking if there's some automated way to tell it to revert back after X amount of time, no. Should be pretty simple, though, with either a delayedCall() or an onComplete. 

[katerlouis]

Sorry if I wasn't clear enough:

 

TweenLite.ticker.fps(15) would set the FPS of ALL tweens to 15, right? 

But I wanna try out to set it lower solely on these 3 animations.

 

Or could I do something like this:

 

// my normal animations
var tween = TweenMax.to(".foo", ...)
var tl = new TimelineMax() ...
                        
// set fps only for the next animations 
TweenMax.ticker.fps(15) // or does this function affect the tweens above aswell?

var slowerTl = new TimelineMax()...
var anotherSlowTl = new TimleineMax()

// how to reset it?
TweenMax.ticker.fps(60);

// Other normal animations
var tween = TweenMax.to(".bar", ...)
var tl = new TimelineMax() ...

 

 

I better don't go that route if fps affects ALL my tweens

[GreenSock]

Right, the ticker.fps() controls how often the whole engine updates. 

 

If you only want to update certain tweens less frequently, you could pause() them and then manually adjust their playhead positions however frequently you want (perhaps with an empty tween that has an onUpdate with logic that only runs ever X number of frames). 

 

Frankly, this strikes me as a much less effective strategy than addressing the broader issue of how things are built (in a way that's really tough on the browser graphics-rendering wise). Totally up to you, of course. Good luck with the project. 

[katerlouis]

Thank you very much!