Safari/IE translate3d lagging/ghosting

[dklessa]

I have an problem with translate3d on Safari and IE11/Edge,

On a page with some scroll effects there shall be just 2 at a time trnslated in position. In Safari there seems to be a lack on positioning, sometimes (not always) the object seems to stuck and then jumping to its correct position.

To position the Elements I decided to use translate3d because of hardware accelleration.

I already tried fixes I found like: -webkit-transform: translateZ(0) -webkit-backface-visibility: hidden/visible -webkit-perspective: 1000

Has someone an idea?

[Beverleyh]

Are you talking about the position:fixed bug in Safari? https://www.google.co.uk/#q=position:fixed+bug+in+safari

[dklessa]

It seems to be a performance problem while rendering the page.

The Elements are not fixed, they stay at their position in DOM and are “moved” by transform: translate3d(), in Chrome and FF this is very smooth.

IE/Edge is a littlebit jumpy (I think scroll isn’t fired often enought), but it’s not breaking the page. In Safari the visible object is sometimes smooth and other times it seems sticky and then jumping to correct position.

[Shikkediel]

The scroll event works slightly different with IE. It is fired after the scrolling has taken place, where all other browsers fire it before any action happens. Which is usually hardly noticeable and probably unrelated here though. Also, IE is rather bad at redrawing pages with large blocks of fixed position elements. It’ll skip beats when repainting the screen. There’s no solution for that unfortunately…

Maybe you can show us a demo? It’ll help determining the cause.

[dklessa]

Is it possible to pm you? I can’t fiddle it down so it would be the best to show you the page where it happens.

Maybe I can provide the link for a short time and then remove it?

[Shikkediel]

If you don’t want the link to remain here, you have some time to edit the post. Otherwise you could try asking a mod if it so happens that the maximum editing time has passed. Probably best if several members can have a look at it of course, no guarantee at all I’d personally know how to fix it.

[dklessa]

OK, I’ll post the link to active project:

…

The elements affected is for example the macbook in the upper left, it is moving while scrolling. You can see the problem on MacOS with Safari.

[Shikkediel]

I missed that… what you also could do is create an account on Codepen or jsfiddle and post an example with only the link. Then later remove the example.

The forum’ll end up with a dead link but I guess that wouldn’t be the first time.

Edit – assuming one can also delete fiddles, I really wouldn’t know.

And I can’t even check on a Mac myself by the way but just have a general look at the code.

[dklessa]

Hello,
sorry for my late answer, I’ll try to post it here once more.

http://www.tigercreate.com

I’ll remove the link later, so just ask me to add it again. Hopefully someone can help me. In IE it is almost fixed, just a little bit jumpy at the moment. It seems that background-attachment: fixed screwed it up. Just Safari is open (and maybe a litte less jumpy on IE/Edge).

[Shikkediel]

I’ve visited the link so I can return there now at any time myself. Looks great in Firefox with smooth scrolling but IE has a few issues. One is that the size of the laptop looks too large. Windows 7 IE 11 here. I suspect the lagging is caused by the exact issue I described earlier. Other browsers with an instantaneous response (as opposed to a smooth scroll) to the mousewheel will fire a scroll event with no delay. But IE takes about 70ms to react, then fires the event afterwards.

Not much time right now but I’ll check again later.

[Shikkediel]

Could you maybe tell me which script exactly takes care of the parallax? Elements are (now?) absolutely positioned so that won’t have as much of an impact as fixed would. Unfortunately I cannot check the behaviour on Mac.

Edit – okay, my machine is pretty quick but I’m seeing some major drops in the frame rate of the page with Chrome dev tools. That’s an indication all animations combined are just a bit much too handle smoothly.

[dklessa]

The parallax.js takes care of the parallax effects. From line 122 to line 328.
What do you mean with to much to handle smoothly? Maybe the videos in parallax elements? I removed those and nothing changed :(

[Shikkediel]

Okay, I found it. It was minified inside the last script on the page. But with the console I can read it normally. In any case, that looks like a good script that’s using the right things to keep the “footprint” down.

Only having remote access makes it hard to debug JS unfortunately, I can’t turn off each of the scripts to see the effect. I was suspecting the embedded videos to be the culprit as well but the next thing you could try is to see what kind of impact disabling the typing animation has…

There’s not a lot you can do about IE besides replacing the script for one that uses mousewheel but that would likely be too much trouble. The delay you see is the difference between using the mousewheel and the browser firing the scroll event. It’s short, but enough to be noticeable.

[Shikkediel]

Actually, there’s probably a way to improve the IE experience. I see the page is using mousewheel.js. With that it would be quite easy to make the scroll event fire yourself.

jQuery(window).mousewheel(function(turn, delta) {

  turn.preventDefault();

  var current = $(this).scrollTop();

  if (delta < 0) $(this).scrollTop(current+135);
  else $(this).scrollTop(current-135);
});

It hijacks default scrolling behaviour though which isn’t usually viewed as correct UI…

Edited – up and down were reversed.

[Author]

Posts