Sketch window stops refreshing on Mac.

[abhikpal]

Test Script: p5-examples/basics/math/sine.py. The bug affects all sketches.

Expected behavior:

Actual behavior The sketch window stops refreshing after a couple of frames are drawn when a newer version of Pyglet (1.3b) is installed.

Errors produced (if any): None

p5 version: 2b96dfc

Python version: 3.6
Operating System: Mac OS

[enricozb]

Which version of pyglet verifiably works? I've tried Pyglet 1.2.4, and I still have this exact issue.

enricozb@enricozb-mbp ~> pip3 show pyglet
Name: pyglet
Version: 1.2.4
Summary: Cross-platform windowing and multimedia library
Home-page: http://pyglet.readthedocs.org/en/pyglet-1.2-maintenance/
Author: Alex Holkner
Author-email: Alex.Holkner@gmail.com
License: BSD
Location: /usr/local/lib/python3.6/site-packages
Requires:

p5 version: 0.3.0a1

Python version: 3.6
Operating System: Mac OS

[abhikpal]

Ahhh.. okay. This is interesting. We haven't been able to consistently reproduce this issue (as I use a linux machine for development and only have access to a Windows for testing). I'll see if I can write some debugging code that you can run.

[enricozb]

Were you ever able to test on a mac before the 0.3.0a1 release? I'm having a hard time finding a commit which supports even the simplest sketch on a mac. Trying to see if the bug appeared in a specific commit.

[kylemcdonald]

fwiw, i can recreate this issue. same version of python, macOS, p5py, and pyglet.

[falquaddoomi]

Same issue on OS X; the window updates jerkily a few times, then stops responding. I doubt that it matters, but I'm running the script from within a virtualenv.

Test script:

from p5 import *

def setup():
    size(640, 360)
    no_stroke()
    background(204)

def draw():
    if mouse_is_pressed:
        fill(random_uniform(255), random_uniform(127), random_uniform(51), 127)
    else:
        fill(255, 15)

    circle_size = random_uniform(low=10, high=80)

    circle((mouse_x, mouse_y), circle_size)

def key_pressed(event):
    background(204)

run()

Expected behavior:
Same as original poster.

Actual behavior
Same as original poster.

Errors produced (if any):
None.

p5 version:

numpy==1.13.2
p5==0.3.0a2
pyglet==1.2.4
PyOpenGL==3.1.0

Python version:
Python 3.6.1

Operating System:

OS X El Capitan
v10.11.6 (15G1611)
MacBook Pro (Retina, 13-inch, Late 2012)
Processor: 2.9 GHz Intel Core i7
Memory: 8 GB 1600 MHz DDR3
Graphics: Intel HD Graphics 4000 1536 MB

[abhikpal]

Were you ever able to test on a mac before the 0.3.0a1 release? I'm having a hard time finding a commit which supports even the simplest sketch on a mac. Trying to see if the bug appeared in a specific commit.

We were facing issues on the Mac even before. I can't remember this exactly, but the v0.1.0dev3 release would be a good place to start. I'll do some digging myself and give you more specific commits to test this weekend.

[kantel]

I now run my testscript on MacOS X 10.10.5 (Yosemite). I got it running (see screenshot) but when I tried to run the examples I got the same behaviour as described above: After a few steps the animation stops and freezes the window. I run on both machines Anaconda Python 3.5.2 with an actual pyglet (1.2.4).

[marcrleonard]

A few things I can confirm:

1. All of the refresh/draw functions are running properly. They are being called at the right time (ie, they are not stuttering like the window).
2. You are using the correct timing method to call the refresh (time.time vs time.clock)

And a few discoveries:

1. I was messing around with some of the gl configs and found that you are using a depreciated method of getting the display config. But after correcting it, it didn't solve the problem.
2. In sketch/base if you change the template to template = pyglet.gl.Config(samples_buffers=1, samples=2, double_buffer=True) you get a ton of flickering (which makes sense after reading about this option), but, you are actually able to see the animation rendering. (NOTE: This is not the actual solution... it introduces some other issues like the buffer not clearing properly)

I have a sneaking suspicion that this is a pyglet issue. I wonder if making the switch to QT would solve this... If that is the end goal, transitioning to QT might kill two birds with one stone.

[abhikpal]

I have a sneaking suspicion that this is a pyglet issue.

Yep. Have been thinking about that as well. I've been hanging out on the Pyglet Google group and they are working really hard on upgrading Pyglet's OpenGL integration (esp. adding support for the core profile: https://groups.google.com/forum/#!topic/pyglet-users/oihWLIDH1S4)

I wonder if making the switch to QT would solve this... If that is the end goal, transitioning to QT might kill two birds with one stone.

I've been playing around with the idea of moving to PyQT for a while, but if we get it working with Pyglet it would be amazing. I'll get to properly work on this in a week or two, and will experiment with the pyglet version that people are working on right now.

[marcrleonard]

Nice! I’ll keep an eye out for any commits.

[akiross]

I would like to add that I'm getting the same issue on (Fedora) Linux.

My system has 2 OpenGL stacks: when using mesa, the problem arises, but it does not when using nvidia drivers (via optirun). Python stack is the same.

$ pip3 freeze
future==0.16.0
numpy==1.14.0
opencv-python==3.4.0.12
p5==0.3.0a2
pyglet==1.3.0
PyOpenGL==3.1.0

I tried using the double buffering solution reported above, but nothing changes. @marcrleonard I would be interested in seeing the config changes you made.

I am currently investigating as well.

[abhikpal]

I'm not entirely sure, but this could be connected to the OpenGL version that p5 gets access to. What version of OpenGL do you get for your mesa and nvidia stacks respectively? (glxinfo | grep OpenGL should find the correct information for you).

[akiross]

mesa:

OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.2.4
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 17.2.4
OpenGL shading language version string: 1.30

Nvidia:

OpenGL core profile version string: 4.6.0 NVIDIA 387.34
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6.0 NVIDIA 387.34
OpenGL shading language version string: 4.60 NVIDIA

EDIT
I am not aware of how processing.org (v3) is rendering, but I have no issues with it. If your shaders are the same, I guess there should be no differences... I tried to explore a little the opengl calls, but apparently the only bugs I get are related to glX (I can post a trace obtained with https://github.com/apitrace/apitrace if it's helpful).

[arihantparsoya]

I think the problem lies in the config passed in this line. When I remove this, the sketch works as correctly. I have posted an issue on stack-overflow and others suggested that it is better to define config from pyglet.window.Window()'s config: https://stackoverflow.com/questions/48983828/pyglet-not-running-as-expected-in-macos/48984962#48984962

[kevinstadler]

Just to confirm that I can reproduce the issue on High Sierra (10.13.3) with pyglet-1.3.1 and PyOpenGL-3.1.0 and the current HEAD (e78c4a8). Using the interactive sample sketch by @falquaddoomi above I actually found out that the window doesn't freeze or stop rendering completely, it is just not redrawn as long as it is in the foreground. With the sketch code above, moving the mouse in front of the sketch nothing happens, but when backgrounding and then foregrounding the window again, the drawings triggered by the mouse hovering over the inactive sketch earlier are all there. It is also possible to only cause a redraw of parts of the sketch by partially obscuring the sketch window with another window.

@parsoyaarihant what would the working order of config/template/window initialisation be? Just removing line 62 gives me a flickering sketch, same with the version from PR #35

[kevinstadler]

I've been playing around with how to best generate a config that works across all platforms (see also #24) but I haven't been able to keep the sketch from stopping to redraw automatically on MacOS. @abhikpal what's the motivation for the two hard-coded config settings? I found out that the samples_buffers config option in

p5/p5/sketch/base.py

Line 48 in e78c4a8

template = pyglet.gl.Config(samples_buffers=1, samples=2)

should actually be called sample_buffers (https://pythonhosted.org/pyglet/api/pyglet.gl.Config-class.html), so I don't think it is actually doing anything? The double_buffer option that fixes things on Raspberry (see #24) also causes the sketch to break (i.e. flicker) on OSX.

[arihantparsoya]

@kevinstadler , I have tried running the code in virtual environment and still the sketch is running as expected. Here is the configuration:

High Sierra               10.13.3
Python                    3.6
pyglet                    1.4.0a1 
PyOpenGL                  3.1.1a1
numpy                     1.14.0

[kevinstadler]

Which code, the one from the repository or your pull request?

[arihantparsoya]

My pull request

[kevinstadler]

Ok cool I finally got it to work! Simply using screen.get_best_config() did not work for me, I had to provide the following two arguments to the template:

template = pyglet.gl.Config(double_buffer=1, sample_buffers=1)
config = screen.get_best_config(template=template)

For any value greater than 0 for sample_buffers in the template, get_best_config() returns a config with sample_buffers=1 on my machine. Also, explicitly passing samples like in the original code does not seem to be necessary as it is automatically set to whatever sample_buffers is. Can you test if this also works for you and add it to the PR if so?

[arihantparsoya]

Okay, this new configuration works for me too. I have added this change in my PR #35

[abhikpal]

Hey @Manindra29 (and everyone on this thread), thanks to #49, do we consider this issue and #9 fixed?