Jump to content
Search Community

odd(bug/glitch?) pixel line when using loco scroll and scroll trigger

proof-of-sock test
Moderator Tag

Recommended Posts

I'm just playing around trying to get things working, noticed an oddity when using scroll trigger with locomotive. There's what seems like a one pixel gap, or interpolation error between slides. The pixel line goes away after the loco scrolling has stopped, seems worse on cards that are the same colour. 

 

Is there any way to avoid this using pinning?

 

https://arcaudio.github.io/index.html

Link to comment
Share on other sites

36 minutes ago, OSUblake said:

Hi proof of sock!

 

It looks like a rendering problem. Maybe try overlapping your sections a couple of pixels so they are not butting against each other.

 

thanks for the feedback. I'm a bit confused how I'd overlap the css backgrounds, maybe there's a z property. It does seem a bit like z culling/classhing like in games engines.

 

Here's the code pen: 

See the Pen ZEePVPG by mldyu (@mldyu) on CodePen

 

Link to comment
Share on other sites

 

Hey @proof-of-sock

 

This actually appears to be a locomotive-scroll issue and not related to GSAP/ScrollTrigger at all.

Here is a demo where it's happening too - and that one doesn't even load GSAP

 

See the Pen ea1c4b04daeba5ac1cd194ff39cec9c6 by akapowl (@akapowl) on CodePen

 

 

 

Have you checked the issues section on locomotive-scroll's GitHub?

Maybe that has been reported already and you'll find a solution over there.

 

On a different note:

 

In your codepen demo above you are creating your ScrollTrigger before you initialize loco-scroll and before you set-up the scrollerProxy. For things to work properly it is pretty much essential to keep a specific order of things.

 

You can always take the demo on the scrollerProxy documentation page as a reference when it comes to this.

 

  • Like 3
Link to comment
Share on other sites

22 minutes ago, akapowl said:

On a different note:

 

In your codepen demo above you are creating your ScrollTrigger before you initialize loco-scroll and before you set-up the scrollerProxy. For things to work properly it is pretty much essential to keep a specific order of things.

 

You can always take the demo on the scrollerProxy documentation page as a reference when it comes to this.

 


I think I found greensock yesterday! And loco today! This particular tech is all incredibly new to me! Which is a testament to how robust and well it's made! 
 

I have to admit to some user error there, it was a last minute change where I thought, maybe this will fix it. Obv my intuition was off!


I will totally have a dig over on github and hope that there's answer or easy fix. If I find something I'll report back for easier searching to weary wonderers. 

  • Like 2
Link to comment
Share on other sites

dayym: https://github.com/locomotivemtl/locomotive-scroll/issues/97

 

it's a rounding error thing? or maybe it's not the same issue, the video is gone from the example. 

 

The quote from the site 

"It happens because of half-pixel computation by browser of the translate value applied to the sections.

I find out better results with value rounded to 2 decimals instead of 3. Even better if only one, or none, but I can't tell if the translation is as smooth as it should then."

 

Link to comment
Share on other sites

1 minute ago, OSUblake said:

 

You could set a negative margin-top in your css for your sections.


margin-top: -2px;

 

that's brilliant

if I add it to the pen from akapowl with only loco:
 

section {
  width: 100vw;
  height: 100vh;
  background-color: rgb(136, 57, 83);;
  margin-top: -2px; // this solves everything
  display: flex;
  flex-direction: column;
  align-items: center;
  justify-content: center;
}

that solves the pixel line I think!

  • Like 3
Link to comment
Share on other sites

5 minutes ago, OSUblake said:

You could set a negative margin-top in your css for your sections.

 

Yeah, I wanted to suggest that at first (as it's essentially what Blake said in the first place).

 

On 100% zoom -1px already fixed the issue for me - but on different browser zoom levels (only tested in Win10 Chrome though) it might still be noticable - so you might have to go as far as -5px maybe - and then you'll have a noticable white space at the end very end of the scroll which you'll have to consider masking with styling somehow.

  • Like 2
Link to comment
Share on other sites

2 minutes ago, akapowl said:

 

Yeah, I wanted to suggest that at first (as it's essentially what Blake said in the first place).

 

On 100% zoom -1px already fixed the issue for me - but on different browser zoom levels (only tested in Win10 Chrome though) it might still be noticable - so you might have to go as far as -5px maybe - and then you'll have a noticable white space at the end very end of the scroll which you'll have to consider masking with styling somehow.

ok so I may need to circle back here and ask you for a bit more specifics on all these minor details, zoom level isn't something i'd considered at all. 

 

overall intention and reason for learning this library is to make interactive web experiences, and with a little bit of js  experiment how to push these into websites into games. Massively love the fact I can animate svg's with greensock, and no pixelation, so I'm over flowing with creative possibilities. I thought using this library would take care of the compatibility side of things, so hadn't really considered things like zoom levels. 

 

Trying to work out how to make a point and click game in the browser and have greensock do the visual heavy lifting, but maybe I'm being a little ambitous!

Link to comment
Share on other sites

6 minutes ago, proof-of-sock said:

ok so I may need to circle back here and ask you for a bit more specifics on all these minor details, zoom level isn't something i'd considered at all. 

 

All I was saying is that if you set a margin of -2px to the sections, the jittery line in between the sections might still be visible if the user changed the zoom of the browser to something very low e.g. - I can still notice it at 33% - it is probably not a big issue though since I don't think there will be many people viewing it at this low zoom levels. I only just wanted to make you aware of that in case that was something that would bother you.

 

 

9 minutes ago, proof-of-sock said:

I thought using this library would take care of the compatibility side of things,

 

GSAP does do an awesome job in taking care of many quirks all across the board, especially when it comes to cross-browser compatibility and reliability - but as mentioned that issue is not related to GSAP but locomotive-scroll.

 

Link to comment
Share on other sites

  • 1 year later...

Hi,

 

I have this exact issue in my website using ScrollSmoother alone, on Chrome. All blocks with backgrounds create a weird 1px glitch on scroll and the negative margin does not fix this for me. Is there any other way to deal with that ?

Link to comment
Share on other sites

 

Try setting will-change: transform on your scroller element - that resolves it for me.

 

On 6/18/2021 at 11:26 PM, akapowl said:

This actually appears to be a locomotive-scroll issue and not related to GSAP/ScrollTrigger at all.

 

☝️ Because that is the case, you might be better off asking over at locomotive-scroll's github issue's, If it doesn't help in your case,

 

https://github.com/locomotivemtl/locomotive-scroll/issues

 

See the Pen ZEoVoea by akapowl (@akapowl) on CodePen

  • Like 3
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...