Odd choppiness to animation?

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]

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.

My thoughts exactly... Tried other native GL demos with the same issue. Probably an issue with my Linux system

…

-sent from my OnePlus X

On Jan 25, 2018 5:52 PM, "Dmitri Shuralyov" ***@***.***> wrote: 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. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#66 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIIciB7EqOF0ADU13YQakb9nVJF9fJGEks5tOQXHgaJpZM4RtSWn> .

[emidoots]

@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.

No, I am getting ~60FPS with a counter I wrote... Just calculating the delta and dividing 1 second by the delta

…

-sent from my OnePlus X On Jan 25, 2018 6:14 PM, "Seth Moeckel" <smeck1999@gmail.com> wrote: My thoughts exactly... Tried other native GL demos with the same issue. Probably an issue with my Linux system

-sent from my OnePlus X

On Jan 25, 2018 5:52 PM, "Dmitri Shuralyov" ***@***.***> wrote: 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. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#66 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIIciB7EqOF0ADU13YQakb9nVJF9fJGEks5tOQXHgaJpZM4RtSWn> .

[emidoots]

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

No worries!!!

…

-sent from my OnePlus X

On Jan 25, 2018 6:20 PM, "Stephen Gutekanst" ***@***.***> wrote: Ah, gotcha. In that case I'm not really sure what the cause would be. Sorry I couldn't help! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#66 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIIciKRkN-ukJ-hjmMfu_obBD7HNcFMjks5tOQw2gaJpZM4RtSWn> .

[dmitshur]

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]

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

C program using just glfw/glfw

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 :)