Jump to content
Search Community

Strange vertical lines between boxes on first play

RolandSoos test
Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

Hi!

 

I'm sorry, but I was unable to reproduce the following issue in CodePen, but maybe you could give me an idea what is going on.

The issue happens in Chrome, Edge and also Firefox, so it is probably not a browser bug. Also this rendering issue happens on the first animation only and not all the time.

 

Reproduce the issue:

  • Open https://smartslider3.com/bugs/chrome/carousel1/
  • Mouse down on one of the blue box and drag your mouse to the left and then release it.
  • While you drag your mouse, my code adjust the progress of the timeline and when you release the mouse, the timeline will .play()
  • The vertical lines appears after you release the mouse and the timeline is playing between the c and d boxes
  • Refresh the browser to try it again

 

The artifact visible on the following video: https://www.youtube.com/watch?v=0f6OU16NlqM

  • 0:13
  • 0:18
  • 0:27
  • 0:49
  • 0:50

 

The issue is not appear when:

  • The animation started with the click on the right arrow
  • If the animation plays 2nd, 3rd etc...
  • The issue do not appear if you drag to the other direction

 


Interesting facts:

  • The drag use the same timeline what the arrow click does. The only difference that when you start a drag: the timeline paused until and the progress adjusted manually and when you release the pointer the timeline plays.
  • The pane size is 1200px, the box size is 400px and the boxes moved with x: -1200px, so there should not be rounding issues
  • I use round props plugin roundProps: "x", so the x values on all boxes should be fine all the time.
  • It happens only between the c and d boxes

 

I tried to reproduce it on Codepen with a basic structure, but nothing like that happens: 

See the Pen aMjKOO by mm00 (@mm00) on CodePen

 

 

Ps.: Setting the background of the container to blue is not an option.

 

 

Link to comment
Share on other sites

Hey Roland,

 

The codePen doesn't really reflect your setup, the issue you're refering to here seems to relate to when you are stopping a drag and immediatelly starting a tween. Looking at the linked example where you report the line, I did see the vertical line but the code there is very dense and I can't spend the time trying to read over it.

 

My guess is that when your code is going from the drag to the tween, somewhere there, sometimes, the different divs don't align perfectly and you end up with a gap between them. Did you say you are only tweening the progress of the timeline when dragging around?

Link to comment
Share on other sites

Thanks @Dipscom! Yeah, I'm sorry I know it is really hard to tell anything with that complex code. Yes, I only adjust the .progress() of the timeline. Also the strange thing, it happens few frame after you release the mouse button. Do you feel too that it happens a little bit later? Also Something there is multiple vertical lines as the timeline plays.

 

I was able to catch the issue with Chrome profiler and the vertical line is visible on the screenshot what Chrome made. The vertical line appears in this example three mousemove events later than the mouse button released. The Javascript happens around that line is a GSAP call "wake"

 

 

Link to comment
Share on other sites

On my machine here, I don't get that line appearing much. Actually, I only saw it once. I'm not sure what could be your setup but it really smells like it's a sub-pixel misalignment to me. Like, the div on the left is at, say, 12.4pixels and the div on the right is at 13.6pixels but the browser rounds that to 12pixels for one and 14pixels for the other.

 

Is your monitor a high dpi one? If it is, do you have one with a lower dpi? See if that happens more on a lower dpi.

 

What is the duration of each tick? Have you got other stuff running on the thread that might bump the tick to a different frame? How long does those calls in your profiled event take?

 

I mean, I am shooting in the dark here, really...

  • Like 1
Link to comment
Share on other sites

Well, It happens on my FHD and also on the WQHD monitor. I was not able to test it on HiDPI. My computer is pretty fast, latest I7 and there is no FPS drop when it happens. 

I wouldn't think it is sub pixel misalignment as I use GSAP roundProps, so the x values always integers. 

 

I created a timestamp for the performance record which displays the X values get written by GSAP:

image.thumb.png.6bc67f4384f4e70c06cef013a7093156.png

 

 

I think the problem lies here. The first three bar is the X value for the first 3 box and the last 3 bar is for the last 3 box. The sum of any first box and any last box should give 1200px in every frame.

In frame before the frame with the vertical line, the math does not work. GSAP calculates 829 and 372 which gives 1201 so there was a miscalculation and this cause the gap between those two.

 

Link to comment
Share on other sites

You certainly appear to have unearthed something with that deep debug dive. I know there was a thread here not too long ago regarding floating point error - Can't remember with it was with you or someone else but, it could be something along those lines.

 

What happens if you turn off the round props? I would expect it to make things worse.

 

Is this width fixed? Do you know? If that is, how about setting boundaries to those X positions? As in, whenever looping, the item has to sit on a position that is based on the previous sibling or on a index times the section width?

 

Still, just throwing wild ideas here until @GreenSock comes by to say something about this potential miscalculation.

Link to comment
Share on other sites

Yeah, it would be worst by turning roundProps off. There would be lines between every boxes. 

 

(Probably I had that floating point conversation few months ago which you remember: https://greensock.com/forums/topic/19625-addpause-the-behavior-is-unexpected/?tab=comments#comment-91640)

 

Here my further findings.

 

1-3 boxes
pt.c = -1200  
v = 0.18125000000000002
pt.s = 1200
= 982.5 rounded -> 983

3-6 boxes
pt.c = -1200 
v = 0.18125000000000002
pt.s = 0
= -217.50000000000003 rounded -> -218
 
 
OShGR6P.png
Link to comment
Share on other sites

@GreenSock one extra question if you do not mind. What do you think why this rounding issue only happened with the drag interaction (Setting progress multiple time on a paused timeline and then play) and does not ever happened with with simple play of the timeline? Is there any rare correlation what you can think of?

 

Is it possible for example that click event happens exactly at a tick while mousemove and the mouseup not snapped to the tick?

Link to comment
Share on other sites

 

12 hours ago, RolandSoos said:

In frame before the frame with the vertical line, the math does not work. GSAP calculates 829 and 372 which gives 1201 so there was a miscalculation and this cause the gap between those two.

 

Interesting thanks for chasing down that error and letting us know, I would have assumed it was a subpixel rendering error. Knowing that it was a calculation error should help with similar issues in the future.

  • Like 1
Link to comment
Share on other sites

Yep, that's the calculation I typically use (I assume you got it from GreenSock source code), but beware that it's not a true rounding - it's more of a "chop off everything after a certain decimal value". For the vast majority of cases, it doesn't matter. 

 

Glad to hear you got everything figured out. 

  • Like 1
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...