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

x/mobile/gl: shapes flicker/jitter without debug.DrawFPS(c) #11696

Closed
shazow opened this issue Jul 13, 2015 · 7 comments
Closed

x/mobile/gl: shapes flicker/jitter without debug.DrawFPS(c) #11696

shazow opened this issue Jul 13, 2015 · 7 comments
Labels
FrozenDueToAge

Comments

@shazow
Copy link
Contributor

shazow commented Jul 13, 2015

(Possibly related to #10688 somehow?)

I'm experiencing flickering/jittery-ness/screen tearing on GL rendering that doesn't use debug.DrawFPS (which strangely fixes it, not sure why). It feels like DrawFPS is somehow enabling double buffering or vsync that is otherwise not there, but I can't figure out why/how that might be the case. Sorry I'm not very experienced with OpenGL.

For example, you can reproduce it in mobile/example/basic with these two changes:

-       gl.Uniform4f(color, 0, green, 0, 1)
+       gl.Uniform4f(color, 0, 0, 0, 1)
...
-       debug.DrawFPS(c)

Not sure why the color needs to be fixed in the above example to reproduce.

I originally noticed this in a somewhat more complex spinning cube example which jitters when debug.DrawFPS(c) is not used. Video: https://www.youtube.com/watch?v=3s68XAJ04Kk

  • go version devel +71832ff Fri Jul 3 21:39:04 2015 +0000 darwin/amd64
  • golang.org/x/mobile commit 7fb893ba (latest)
  • Mac OSX 10.9.5 on a 13" MBP (Intel Iris GPU).
@crawshaw crawshaw self-assigned this Jul 13, 2015
@crawshaw
Copy link
Member

Thanks, I can reproduce this during resize on OS X with your diff. Not sure what the problem is yet. Do you see it any other time than resize?

@shazow
Copy link
Contributor Author

shazow commented Jul 13, 2015

@crawshaw For me, it happens even without resizing. You can see in the video with the spinning cube (I edited it into the original post).

To clarify, the mobile/example/basic jitter happens when I move the triangle around.

@crawshaw
Copy link
Member

I have a working theory, but as I'm only seeing it on resize I'm not certain. @shazow, could you please try the change in https://go-review.googlesource.com/12123? Gerrit offers some instructions in the top-right corner, something like:

git fetch https://go.googlesource.com/mobile refs/changes/23/12123/1 && git checkout FETCH_HEAD

@shazow
Copy link
Contributor Author

shazow commented Jul 13, 2015

Yup, that's much better! Fixes it for both cases (basic example and my spinning cube) on my machine.

@crawshaw
Copy link
Member

Great, thank you for giving me a way to reproduce this. I'll think through whether I can improve on that CL and try to send something out tomorrow.

@shazow
Copy link
Contributor Author

shazow commented Jul 13, 2015

Happy to help, thanks for the superquick turnaround. Let me know if I can help with testing other solutions.

@gopherbot
Copy link

CL https://golang.org/cl/12123 mentions this issue.

@golang golang locked and limited conversation to collaborators Jul 13, 2016
imWildCat pushed a commit to imWildCat/go-mobile that referenced this issue Apr 10, 2021
@crawshaw
app: ensure gl work is drained before endDraw
76085d4 
If a frame draw cycle does not end in a blocking GL call,
then the app package may process the <-endDraw before the
final <-gl.WorkAvailable, meaning some GL calls miss the
frame.

So we make sure the final GL call for a frame is blocking.

Fixes golang/go#11696.
Fixes golang/go#10688.

Change-Id: I39772a3308c98947b1f0838ad58d1d406a711e7f
Reviewed-on: https://go-review.googlesource.com/12123
Reviewed-by: Nigel Tao <nigeltao@golang.org>
imWildCat pushed a commit to imWildCat/go-mobile that referenced this issue Apr 11, 2021
@crawshaw
app: ensure gl work is drained before endDraw
6837e8b 
If a frame draw cycle does not end in a blocking GL call,
then the app package may process the <-endDraw before the
final <-gl.WorkAvailable, meaning some GL calls miss the
frame.

So we make sure the final GL call for a frame is blocking.

Fixes golang/go#11696.
Fixes golang/go#10688.

Change-Id: I39772a3308c98947b1f0838ad58d1d406a711e7f
Reviewed-on: https://go-review.googlesource.com/12123
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@shazow @crawshaw @gopherbot