Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Odd choppiness to animation? #66

Open
ghost opened this issue Jan 25, 2018 · 8 comments
Open

Odd choppiness to animation? #66

ghost opened this issue Jan 25, 2018 · 8 comments

Comments

@ghost
Copy link

ghost commented Jan 25, 2018

I was checking out the demo (41-cube) and noticed some chopping/lag... I wonder if this is a Go-GL issue or just something with the way to program was written.
@dmitshur
Copy link
Member

I don't see any choppiness or lag on my computer. It's a MacBook Pro with AMD Radeon HD 6770M 1 GB video card, running macOS 10.13.3. It seems to run locked to vsync at 60 hz (my monitor's refresh rate), without any skipped or dropped frames. I'm running go1.10beta2, but I never had issues with Go 1.9 or earlier.

What system do you have (CPU, GPU, OS, Go version, etc.)? If other people with similar systems can reproduce your issue, then it might be an issue in the code.

One way you can find out if the issue is with Go or elsewhere is by running a similar example from the GLFW C library (http://www.glfw.org/). If it happens there too, then it's not Go. If it doesn't, then the issue is somewhere here.

@ghost
Copy link
Author

ghost commented Jan 25, 2018 via email

@emidoots
Copy link
Member

@rucuriousyet are you getting > 60 FPS ? in my experience, vsync is usually disabled (or broken) by the driver and the higher framerate can cause choppiness & input lag due to having less CPU/GPU cycles when needed.

@ghost
Copy link
Author

ghost commented Jan 25, 2018 via email

@emidoots
Copy link
Member

Ah, gotcha. In that case I'm not really sure what the cause would be. Sorry I couldn't help!

@ghost
Copy link
Author

ghost commented Jan 25, 2018 via email

@dmitshur
Copy link
Member

dmitshur commented Jan 25, 2018 •
edited
Loading

Oh, I just noticed cube.go isn't turning vsync on. Maybe it should be?

@rucuriousyet Can you try adding glfw.SwapInterval(1) // Vsync. to the source code (after window is created and its context is made current) and see if that helps your issue?

@pwaller
Copy link
Member

pwaller commented Nov 25, 2019

I took a look at this. My first inclination was to dismiss it, as I couldn't reproduce the jank. But I looked very closely and did perceive a little jank, occasionally. A tiny amount, maybe once every 100 frames. Barely perceptible unless you look for it continuously and closely for a while.

So I decided to measure it. Here's a histogram, with milliseconds-per-frame on the x axis:

go-gl/glfw

image

C program using just glfw/glfw

image

Thoughts

Note the extremes on the left and the right. This data only represents a few seconds of runtime, so those individual data points are significant.

In any case I don't know if the effect I'm seeing is the same as @rucuriousyet is reporting, since we don't know what kind of choppiness he was experiencing. What we need is more data. Can someone report back with their frame timings? If you dump them in a file and attach them here, I can make a histogram. I'm just taking the elapsed time variable in gl41core-cube.

You can see there is quite a wide skew. I have run with GODEBUG=gctrace=1,schedtrace=1, but don't see anything correlating with the long frames on the Go side. There is no garbage collection occurring. This effect is observable even if I turn off all code except for glfw.SwapBuffer.

Based on what I've seen I think this could be a real (but subtle) effect, but I don't know what is at fault. It looks like it is glfw or something deeper in the stack. (I'm on recentish Nvidia drivers on Linux on a powerful card). The effect is so subtle to my eye that if it were present in other software I may not have noticed it. I can notice the effect worsening if I inject random delays of 1-5ms, implying that the delays shown in the above histograms might be the cause.

We're at the limits of what I'm able to debug for now. It would be interesting if someone is able to grab a fine time resolution trace and figure out where the time is getting lost. Maybe there is a bug in to be fixed somewhere in the stack :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@pwaller @dmitshur @emidoots