search

FlorianRhiem / pyGLFW

Python bindings for GLFW
MIT License
232 stars 36 forks source link

Compatibility with github's CI Mac OS X runner images #80

Closed HinTak closed 3 months ago

HinTak commented 3 months ago

Sorry for filing it here - I suspect this discussion might belong to github's actions/runner-images repo, rather than here. That said, I have a curious issue trying to use glfw inside github's own CI action against its mac os x runners. What I have is something like this:

    if not glfw.init():
        raise RuntimeError('glfw.init() failed')
    glfw.window_hint(glfw.VISIBLE, glfw.FALSE)   # with or without this line
    glfw.window_hint(glfw.STENCIL_BITS, 8)
    window = glfw.create_window(640, 480, '', None, None)
    assert window is not None
    glfw.make_context_current(window)

    print(glGetString(GL_VERSION))

On linux and on user's mac os x desktop, this gives something normal and carry on. But within github's CI, against the mac os x hosts (only those; I think it also doesn't work for windows, but that's a different issue), this gives a nullptr for GL_VERSION, and also GLFWError: (65545) b'NSGL: Failed to find a suitable pixel format'. So my first question is, are there people using glfw on github's CI against mac os x runners successfully?

The background of this is https://github.com/kyamagu/skia-python/issues/214 , but at this point somewhat unrelated - I was trying to use github's CI to replicate a mac user's desktop issue (since I am on Linux only), but github's CI behaves entirely differently from user's mac desktop, so now I have two separate issues.

FlorianRhiem commented 3 months ago

Hey @HinTak,

in the past, I've had issues in macOS requiring me to set some more window hints (e.g. setting the version to 3.3, core profile and setting the forward compatibility flag), so that might be something worth trying. The error message you get is produced nsgl_context.m and the code above which assembles the attribs includes some checks for the context version, samples, etc, so perhaps try being specific with the context and framebuffer flags and perhaps vary them a bit.

Some more generic suggestions:

HinTak commented 3 months ago

@FlorianRhiem Thanks for the quick response!

This is all within github's CI system: https://github.com/kyamagu/skia-python/blob/e0b030c14e33f70880cfcc502eaeed898a77fc3c/.github/workflows/ci.yml#L127 ( I am trying to add glfw to the MAC OS X line below, which is missing it from ages ago). It seems to be downloading a file called glfw-2.7.0-py2.py27.py3.py30.py31.py32.py33.py34.py35.py36.py37.py38-none-macosx_10_6_intel.whl via pip. It says it is downloading (97 kB) - that sounds way too small to have a bundled GLFW? - I did suspect that maybe it is picking up something strange from say, macport (with a glfw linked against Xquartz?). I'll need to investigate. Is it possible to query from within pyglfw where the location it is loading glfw from? I really only have the CI logs to work with, after I send in different changes and getting the logs back. But of course I can add a "ls -lR" to the CI run commands and see what it returns...

This issue seems to be specific to github CI (and have been the same for possibly 4 years); desktop mac os x users don't seem to have this problem (they have something else unrelated to glfw I think).

I have looked around and saw the tips about mac os needing core profile, etc, and have an extended version of the python code like below, but this does not improve things:

    if not glfw.init():
        raise RuntimeError('glfw.init() failed')
    glfw.window_hint(glfw.VISIBLE, glfw.FALSE)
    glfw.window_hint(glfw.STENCIL_BITS, 8)
    # See https://www.glfw.org/faq#macos
    glfw.window_hint(glfw.CONTEXT_VERSION_MAJOR, 3)
    glfw.window_hint(glfw.CONTEXT_VERSION_MINOR, 2)
    glfw.window_hint(glfw.OPENGL_FORWARD_COMPAT, True)
    glfw.window_hint(glfw.OPENGL_PROFILE, glfw.OPENGL_CORE_PROFILE)
    window = glfw.create_window(640, 480, '', None, None)
    assert window is not None
    glfw.make_context_current(window)

I'll possibly try to poke around and see what' that 97K wheel is made of. Thanks.

FlorianRhiem commented 3 months ago

You can print glfw._glfw to see the actual library that was loaded. Try using a binary downloaded from https://www.glfw.org/download.html or one built on that system.

The macOS binary is only 77kB zipped all by itself, so that wheel size looks about right.

HinTak commented 3 months ago

The 97k wheel seems to match the description at the bottom of: https://pypi.org/project/glfw/#files and on mac os x 14 (which is arm64 based) it gets a 94k wheel which matches the other one too.

HinTak commented 3 months ago

Thanks a lot. The glfw._glfw tips is useful to know. I'll add that to pytest and see what it says...

HinTak commented 3 months ago

@FlorianRhiem I forgot to mention that using glut directly works as expected against github CI's mac os x action runners. So this is something specific to the github CI + mac os x + glfw/pyglfw combo. Changing any of the 3 (desktop mac os, Linux, or glut) gives a working setup. At the moment I am leaning towards something strange on github CI. It may have a libglfw from mac port, for example. I need to poke it a bit.

HinTak commented 3 months ago

The libglfw being used is

'/private/var/folders/n8/w901w1rn4ldg6yskstndsj200000gn/T/cibw-run-sngkcv1e/cp311-macosx_x86_64/venv-test/lib/python3.11/site-packages/glfw/libglfw.3.dylib', handle 208be2e20 at 0x10c6fe5d0>

That seems to be the package bundled one. So needs to keep looking...

FlorianRhiem commented 3 months ago

As suggested before, It might be worth a try to use one downloaded from https://www.glfw.org/download.html as the pyGLFW wheels currently provide GLFW 3.3 binaries instead of 3.4. Perhaps this is a bug fixed in 3.4, so downloading that binary and setting PYGLFW_LIBRARY to the path of the library might help.

HinTak commented 3 months ago

I have downloaded 3.4 binary, bundled it in the sample repo, adding the print glfw._glfw to verify that it is using the downloaded binary, and it is still failing. The code is at: https://github.com/HinTak/skia-python-examples/blob/8d123f3b996577126b407390164381a14acf7dc8/.github/workflows/ci.yml#L26

Note that it passes the sdl2 and the glut python lines, so those two don't seem to have a problem getting a GL context inside github's CI. If you want to experiment, I think you can just modify the top of the CI line to do so on "pull", and create a pull on that repo, and it would run on pull.

HinTak commented 3 months ago

I have made a test case and filed upstream: https://github.com/glfw/glfw/issues/2570