pyopengl-users — Discussion of all PyOpenGL matters.

[PyOpenGL-Users] Hacked, I assume

[Francis M. <f_m...@ya...>]

Dear Sir/Madam

At the web page http://mcfletch.github.io/pyopengl/documentation/index.html, under "Developing emol (ShowMeDo video tutorials) by Erik Thompson -- develops a molecular viewer using wxPython, PyOpenGL and bzr", the website referenced seems to have been hacked.

Francis Mangion

Re: [PyOpenGL-Users] glMapBufferRange

[Ian M. <ia...@ge...>]

On Tue, Jul 13, 2021 at 6:42 AM Jeff Fayman <jf...@jn...> wrote:

> Trying to use glMapBufferRange and getting the following error:
>
>
>
> OpenGL.error.NullFunctionError: Attempt to call an undefined function
> glMapBufferRange, check for bool(glMapBufferRange) before calling
>
>
>
> What am I missing here.  All other OpenGL functions that I have used are
> available and functioning properly.
>

This is an OpenGL 3.0 function. Does your hardware support OpenGL 3.0
(likely), have you created an OpenGL 3.0+ context, and have you bound it?

[PyOpenGL-Users] glMapBufferRange

[Jeff F. <jf...@jn...>]

Trying to use glMapBufferRange and getting the following error:

OpenGL.error.NullFunctionError: Attempt to call an undefined function glMapBufferRange, check for bool(glMapBufferRange) before calling

What am I missing here.  All other OpenGL functions that I have used are available and functioning properly.

Thanks.

[PyOpenGL-Users] MoltenGL

[Jim E. <edw...@gm...>]

I would like to port a recent pyopenGL app to the mac - does anyone have
experience, examples or documentation of how to use this with MoltenGL?

Thanks,

-- 

Jim Edwards

[PyOpenGL-Users] Trying to get PyOpenGL working with PySide2

[J.L.M. <jl...@gm...>]

I am unsure how to make QT, PySide2, and PyOpenGL all work together. I
think I've found at least three different ways to create an OpenGL widget.
What I have below is a UI created in QT Designer and then converted into
Python, a subclass, and the main program. The problem I'm having is that
initalizeGL and paintGL are never getting called. resizeGL is getting
called.

from PySide2.QtCore import (QCoreApplication, QDate, QDateTime, QMetaObject,
    QObject, QPoint, QRect, QSize, QTime, QUrl, Qt)
from PySide2.QtGui import (QBrush, QColor, QConicalGradient, QCursor, QFont,
    QFontDatabase, QIcon, QKeySequence, QLinearGradient, QPalette, QPainter,
    QPixmap, QRadialGradient)
from PySide2.QtWidgets import *

from canvas import Canvas

class Ui_MainWindow(object):
    def setupUi(self, MainWindow):
        if not MainWindow.objectName():
            MainWindow.setObjectName(u"MainWindow")
        MainWindow.resize(984, 724)
        self.centralwidget = QWidget(MainWindow)
        self.centralwidget.setObjectName(u"centralwidget")
        self.horizontalLayout = QHBoxLayout(self.centralwidget)
        self.horizontalLayout.setObjectName(u"horizontalLayout")
        self.verticalLayout = QVBoxLayout()
        self.verticalLayout.setObjectName(u"verticalLayout")
        self.horizontalLayout.addLayout(self.verticalLayout)

        self.openGLWidget = Canvas(self.centralwidget)
        self.openGLWidget.setObjectName(u"openGLWidget")

        self.horizontalLayout.addWidget(self.openGLWidget)

        self.horizontalLayout.setStretch(1, 1)
        MainWindow.setCentralWidget(self.centralwidget)


-------------------------------------------------------------------------------------------------------------------------------------

from PySide2.QtWidgets import QOpenGLWidget
from OpenGL.GL import *

class Canvas(QOpenGLWidget):
    def __init__(self, parent = None):
        super().__init__(parent)

    def initializeGl(self):
        print("set clear color", flush=True)
        initializeOpenGLFunctions()
        glClearColor(1.0, 0.0, 0.0, 1.0)

    def resizeGL(self, width, height):
        print("resize", flush=True)

    def paingGL(self):
        print("paint", flush=True)
        self.glClear(GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH_BUFFER_BIT)

-----------------------------------------------------------------------------------------------------------------------------------------------------
import sys
from PySide2.QtWidgets import QApplication, QMainWindow
from PySide2.QtCore import QFile
from main_window import Ui_MainWindow

class MainWindow(QMainWindow):
    def __init__(self):
        super().__init__()
        self.ui = Ui_MainWindow()
        self.ui.setupUi(self)

if __name__ == "__main__":
    app = QApplication(sys.argv)

    window = MainWindow()
    window.show()

    sys.exit(app.exec_())

Re: [PyOpenGL-Users] No valid context

[physkets <phy...@tu...>]

Okay, so with a lot of help from Florian Rhiem of pyGLFW, I was able to figure out that the issue was because of the wrong 'platform' being chosen. Wayland requires that the EGL platform be used, while the GLX platform was being used. So using the environment variable: `PYOPENGL_PLATFORM=egl` fixed this problem.

To see the full discussion that lead to this, refer to:
https://github.com/FlorianRhiem/pyGLFW/issues/49

I also found someone else who had a issue due to the same reason, and was equally stumped due to the error not pointing them in the right direction:
https://stackoverflow.com/questions/42185728/why-is-glgenvertexarrays-undefined-in-pyopengl-when-using-gtkglarea

Can the appropriate platform be used by detecting the environment appropriately? Possibly from the 'XDG_SESSION_TYPE' environment variable obtainable from `os.environ`?

Re: [PyOpenGL-Users] No valid context

[physkets <phy...@tu...>]

Thanks for the pointers, I will take a look.

One other thing that's bothering me is:

> File "/usr/lib/python3.8/site-packages/OpenGL/GL/VERSION/GL_2_0.py", line 469, in glVertexAttribPointer>    contextdata.setValue( key, array )

Why does pyOpenGL use the file for version 2? This is what gets used even when I set the context version hints for pyGLFW. Any idea?

Re: [PyOpenGL-Users] No valid context

[Ian M. <ia...@ge...>]

On Tue, Apr 21, 2020 at 11:26 PM physkets <phy...@tu...> wrote:

> Offhand, I am surprised that `glVertexAttribPointer(...)` would be the
>> call to fail; there are plenty of other GL calls that should have failed
>> beforehand, if indeed they didn't fail. GLFW creates a context, and it
>> looks like you're setting it as current. If that code does what it looks
>> like, correctly, then the error especially wouldn't make sense. I would
>> suggest to try validating the context, perhaps creating a debug context.
>>
> Can you point me to some resources that explain how I can do that?
>
In general, Google is your friend on this, but I'll give a shoutout to the
OpenGL Wiki.

PyOpenGL conveniently does user-level OpenGL error checking
(`glGetError()`, etc.) for you, but this is separate from a debug context
per-se, which is a driver-level flag that enables additional validation
within the context itself.

I don't know how this works in Python, since if I need to do
robust/fast/reliable graphics, I do it in C++, but in that language it's as
easy as:

void __stdcall callback_err_gl(GLenum source,GLenum type,GLuint id,
GLenum severity,GLsizei length,GLchar const* message,void const* user_param)
 {

         //[Notice errors here . . .]

}

int main(int argc, char* argv[]) {

         //[...]

         glfwWindowHint(GLFW_OPENGL_DEBUG_CONTEXT, GLFW_TRUE);

         glDebugMessageCallback(callback_err_gl,nullptr);

         //[...]

         return 0;

}



This should be a reasonable guide as you search for the Python binding's
equivalent.


> What happens if you just try drawing an empty window without the
>> problematic setup code?
>>
> It works if I simply set a single colour using `glClearColor()`. There is
> no crash, and it displays a window with the right color.
>
This suggests to me that the OpenGL context is working, and that there's
some peculiarity with the `glVertexAttribPointer(...)` function itself. I
have no idea what that might be, though. It working for me on a different
platform, and other GL calls succeeding suggests a possible bug.

Also, why did you comment the context creation hints?
>>
> I did not think those ones were important. I assume it will use that
> latest version of opengl that I have. Is that not true?
>
I don't know whether it's mandated to be a particular way by the OpenGL
specification (I don't think it is, and the spec. is version-specific
anyway), but my experience has been that when you request a context, you'll
get back whatever the driver wants to give you. This is often the highest
OpenGL version your hardware supports (which is not necessarily a good
thing, mind), but it's sometimes not. The point is, you want to *know* what
you're getting. Specifying the parameters is a good way to do that.

You might also try seeing if you can reproduce the problem in RenderDoc
<https://renderdoc.org/>? (Although IDK how well it plays with Python . . .)

Ian

Re: [PyOpenGL-Users] No valid context

[physkets <phy...@tu...>]

> FWIW I can't reproduce the issue here, although I note that line 121 mentioned in the traceback does not correspond to that line in the attached code, so I don't know if the difference matters.
>
Sorry about that, I added those commented hint lines later, but used the error output from before. Buy it still gives me the same issue.

>
> Offhand, I am surprised that `glVertexAttribPointer(...)` would be the call to fail; there are plenty of other GL calls that should have failed beforehand, if indeed they didn't fail. GLFW creates a context, and it looks like you're setting it as current. If that code does what it looks like, correctly, then the error especially wouldn't make sense. I would suggest to try validating the context, perhaps creating a debug context.
>
Can you point me to some resources that explain how I can do that?

> What happens if you just try drawing an empty window without the problematic setup code?
>
It works if I simply set a single colour using `glClearColor()`. There is no crash, and it displays a window with the right color.

> Also, why did you comment the context creation hints?
>
I did not think those ones were important. I assume it will use that latest version of opengl that I have. Is that not true?

Re: [PyOpenGL-Users] No valid context

[Ian M. <ia...@ge...>]

On Sun, Apr 19, 2020 at 8:20 AM physkets via PyOpenGL-Users <
pyo...@li...> wrote:

> Hi!
>
> I'm trying to use pyGLFW to make a simple coloured quad, but I fail with
> the following error message:
>
> Traceback (most recent call last):  File "first.py", line 121, in
> <module>    gl.glVertexAttribPointer(LOCATION, 2, gl.GL_FLOAT, False,
> STRIDE, OFFSET)  File
> "/usr/lib/python3.8/site-packages/OpenGL/latebind.py", line 63, in
> __call__    return self.wrapperFunction( self.baseFunction, *args, **named
> )  File "/usr/lib/python3.8/site-packages/OpenGL/GL/VERSION/GL_2_0.py",
> line 469, in glVertexAttribPointer    contextdata.setValue( key, array )
> File "/usr/lib/python3.8/site-packages/OpenGL/contextdata.py", line 58, in
> setValue    context = getContext( context )  File
> "/usr/lib/python3.8/site-packages/OpenGL/contextdata.py", line 40, in
> getContext    raise error.Error(OpenGL.error.Error: Attempt to retrieve
> context when no valid context
> I am attaching the program that gives me that error along with the shaders.
>
> Am I doing something wrong?
>

FWIW I can't reproduce the issue here, although I note that line 121
mentioned in the traceback does not correspond to that line in the attached
code, so I don't know if the difference matters. Anyway, the code works as
I would expect (Win x64 Py3.7.3, PyOpenGL 3.1.5).

Offhand, I am surprised that `glVertexAttribPointer(...)` would be the call
to fail; there are plenty of other GL calls that should have failed
beforehand, if indeed they didn't fail. GLFW creates a context, and it
looks like you're setting it as current. If that code does what it looks
like, correctly, then the error especially wouldn't make sense. I would
suggest to try validating the context, perhaps creating a debug context.

What happens if you just try drawing an empty window without the
problematic setup code? Also, why did you comment the context creation
hints?

Ian

[PyOpenGL-Users] No valid context

[physkets <phy...@tu...>]

Hi!

I'm trying to use pyGLFW to make a simple coloured quad, but I fail with the following error message:

Traceback (most recent call last):  File "first.py", line 121, in <module>    gl.glVertexAttribPointer(LOCATION, 2, gl.GL_FLOAT, False, STRIDE, OFFSET)  File "/usr/lib/python3.8/site-packages/OpenGL/latebind.py", line 63, in __call__    return self.wrapperFunction( self.baseFunction, *args, **named )  File "/usr/lib/python3.8/site-packages/OpenGL/GL/VERSION/GL_2_0.py", line 469, in glVertexAttribPointer    contextdata.setValue( key, array )  File "/usr/lib/python3.8/site-packages/OpenGL/contextdata.py", line 58, in setValue    context = getContext( context )  File "/usr/lib/python3.8/site-packages/OpenGL/contextdata.py", line 40, in getContext    raise error.Error(OpenGL.error.Error: Attempt to retrieve context when no valid context
I am attaching the program that gives me that error along with the shaders.

Am I doing something wrong?

This is information from glxinfo:

OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) HD Graphics 620 (KBL GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.0.4
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6 (Compatibility Profile) Mesa 20.0.4
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.0.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:
Also, I'm on a Wayland-based compositor, and am using GLFW compiled for wayland. Might that be an issue?

[PyOpenGL-Users] Install errors pyopengl-accelerate on Windows 10 with Python 3.7 64-bits

[Jacco H. - LR <J.M...@tu...>]

When installing pyopengl-accelerate with pip on Windows 10 with Python 3.7 (64-bits) I consistently get an VS Build error for cl.exe, no matter how many SDks, Visual Studio Build tools, etc.  I install.

The only working solution for us has been to roll back to Python 3.6.8 (64 bits) where this problem somehow does not exist.

For new users of our program (BlueSky on GitHub) this is very annoying as they first will try the newest version of Python and then always run into this problem.

Pyopengl installs without any problems, so do the other packages, except for pyopengl-accelerate.

Best regards,
    Jacco Hoekstra

[PyOpenGL-Users] Installation error for PyOpenGL in Mac

[Ambareesh S. N. J. <asr...@en...>]

Hi,

I'm using MacOS Mojave (10.14.5), and I'm trying to install PyOpenGL using
my anaconda
I tried:

  pip install PyOpenGL PyOpenGL_accelerate


and it is failing with error code 1. I've taken the log of the error and
attached it as a .txt file. Could you help me out with this?


<Re-posting, as I'd made the earlier post, before subscribing to the mail
list, Apologies>
Best,
*Ambareesh*

Re: [PyOpenGL-Users] Undefined glutInit

[Andrew G. <ape...@gm...>]

By the way, I meant this as a bug report.  Even if GLUT is not so good to use, it would still be good to fix this bug since a bunch of demo scripts won’t work.

Is this mailing list the right place to report a bug?  Or should I create an issue on github (https://github.com/mcfletch/pyopengl <https://github.com/mcfletch/pyopengl>)? 

Thanks,
Andrew 

> On May 9, 2019, at 2:36 PM, Andrew Grace <ape...@gm...> wrote:
> 
> I’m getting this error:
> 
> "OpenGL.error.NullFunctionError: Attempt to call an undefined function glutInit, check for bool(glutInit) before calling”
> 
> I’m using MacOS 10.13.6 High Sierra, and I’m getting the error when trying to use PyOpenGL 3.1.0.  I get the error whether using Python 2.7.16 or 3.7.3.
> 
> I installed pyopengl with the command `pip install pyOpenGL` and I installed glut with the command `brew install freeglut`.
> 
> I’m guessing that there is a library loading issue.  So, I’ll describe where the glut binaries are located.
> 
> When freeglut gets installed, it puts a symlink into `/usr/local/lib/libglut.dylib` which points to where homebrew installed freeglut in `/usr/local/Cellar/freeglut/3.0.0/lib`.
> 
> When I just try searching Google for the error I’m getting, I have only found Windows users discussing it.  The answers were typically to suggest using a precompiled wheel (that includes glut binaries) rather than installing it from pip, or maybe copying the glut.dll file into the same directory that the python program is running.  I’ve tried to copy libglut.dylib into the same directory, and I still got the same error.
> 
> I tried using pudb to walk through the code and see if I could find anything obvious.  The line it seems to fail on is `glutInit special.py`.  I’m unfamiliar with the code, so I don’t know how to debug further.
> 
> Please help!
> 
> Thanks,
> Andrew

Re: [PyOpenGL-Users] Undefined glutInit

[Chris B. - N. F. <chr...@no...>]

On May 10, 2019, at 8:29 AM, Ian Mallett <ia...@ge...> wrote:

On Fri, May 10, 2019 at 9:18 AM Andrew Grace <ape...@gm...> wrote:

> I wanted to use pyOpenGL to learn about OpenGL (rather than having to use
> C or C++).  What would you recommend instead of GLUT?  GLFW?
>

Is embedding OpenGL in tkInter easy enough these days? (Or wx or qt). We’re
using it with wx, though as part of a substantial app — not sure how easy
it is to whip out a single window these days.


trying to pip install pyOpenGL-accelerate (on MacOS High Sierra) currently
> fails and throws a stack trace.
>

You might try conda/conda-forge. I think those builds are solid.

-CHB

Re: [PyOpenGL-Users] Undefined glutInit

[Ian M. <ia...@ge...>]

 On Fri, May 10, 2019 at 9:18 AM Andrew Grace <ape...@gm...> wrote:

> I wanted to use pyOpenGL to learn about OpenGL (rather than having to use
> C or C++).

This is how I got my start in graphics, FWIW.

What would you recommend instead of GLUT?  GLFW?
>
GLFW is definitely my recommendation for experimenting in C++. It's
probably good in Python as-well, but I haven't used it, since I don't do a
lot of graphics development in that language anymore. That said, in Python,
I have used (and still use for the occasional one-off) pygame
<https://www.pygame.org/news>, which supports graphics/OpenGL specifically
on OSX. There's an active support community for it too. Really anything
would be better than GLUT, though.

Re: [PyOpenGL-Users] Undefined glutInit

[Ian M. <ia...@ge...>]

On Fri, May 10, 2019 at 9:18 AM Andrew Grace <ape...@gm...> wrote:

> I wanted to use pyOpenGL to learn about OpenGL (rather than having to use
> C or C++).  What would you recommend instead of GLUT?  GLFW?
>
> There does seem to be a broken build, at least for MacOS.  For example,
> trying to pip install pyOpenGL-accelerate (on MacOS High Sierra) currently
> fails and throws a stack trace.
>
> Thanks,
> Andrew
>

Re: [PyOpenGL-Users] Undefined glutInit

[Ian M. <ia...@ge...>]

Hi,

It is unclear to me whether this is your code or someone else's, and I am
not personally familiar with OSX. The usual culprit for
`NullFunctionError`s is the lack of an OpenGL context, but I don't think
`glutInit(...)` is one of the ones that requires (or indeed can succeed)
the creation of one. I confirm your assessment of other programmers: there
was some kind of bug with pip installs a while back. Given the simplicity
of the problem, I'd expect some kind of setup issue, although I certainly
don't know how to resolve it.

Anyway, if this is your code, I would suggest not using GLUT, or at-least
trying to reverse-engineer from a working sample. GLUT is ancient and
bad—although in-fairness (and to my distress) people regularly still do use
GLUT, in the face of better alternatives. If this is not your code, then
it's worth a bug report to whichever project it is.

Ian

[PyOpenGL-Users] Undefined glutInit

[Andrew G. <ape...@gm...>]

I’m getting this error:

"OpenGL.error.NullFunctionError: Attempt to call an undefined function glutInit, check for bool(glutInit) before calling”

I’m using MacOS 10.13.6 High Sierra, and I’m getting the error when trying to use PyOpenGL 3.1.0.  I get the error whether using Python 2.7.16 or 3.7.3.

I installed pyopengl with the command `pip install pyOpenGL` and I installed glut with the command `brew install freeglut`.

I’m guessing that there is a library loading issue.  So, I’ll describe where the glut binaries are located.

When freeglut gets installed, it puts a symlink into `/usr/local/lib/libglut.dylib` which points to where homebrew installed freeglut in `/usr/local/Cellar/freeglut/3.0.0/lib`.

When I just try searching Google for the error I’m getting, I have only found Windows users discussing it.  The answers were typically to suggest using a precompiled wheel (that includes glut binaries) rather than installing it from pip, or maybe copying the glut.dll file into the same directory that the python program is running.  I’ve tried to copy libglut.dylib into the same directory, and I still got the same error.

I tried using pudb to walk through the code and see if I could find anything obvious.  The line it seems to fail on is `glutInit special.py`.  I’m unfamiliar with the code, so I don’t know how to debug further.

Please help!

Thanks,
Andrew

[PyOpenGL-Users] EGL on linux without X

[Thomas P. <ta...@gm...>]

I am trying to use PyOpenGL with an EGL context on a linux system without X
server.

I create a context similar to
https://github.com/tensorflow/lucid/blob/master/lucid/misc/gl/glcontext.py#L79


Context seems fine, but I get errors when calling various OpenGL functions,
e.g.

*OpenGL.error.NullFunctionError: Attempt to call an undefined function
glTexStorage2D, check for bool(glTexStorage2D) before calling*

Any ideas what's the problem?

[PyOpenGL-Users] python3 bytes vs str in getExtensionProcedure

[Rob M. - N. A. <rob...@no...>]

In python 3 (and pyopengl 3.1.1a1), this works:

    gl.platform.PLATFORM.getExtensionProcedure(b"glGenBuffers")

but this fails, returning None:

    gl.platform.PLATFORM.getExtensionProcedure("glGenBuffers")

on any platform. The difference being the bytes vs str in the argument.

This is a corner case to be sure because I'm trying to support some very
old legacy OpenGL implementations (OpenGL 2.1 because wxPython on Windows),
but maybe this will save someone else, oh, I don't know, like 8 or 10 hours
debugging... :)

Rob

[PyOpenGL-Users] osmesa platform not working

[Richard G. <ric...@cb...>]

Hello,

I am trying to get a project (pyoptools) to work which requires using 
pyopengl with the osmesa platform and am running into an issue.

I can normally import OpenGL.GL fine, however after setting the 
environment variable PYOPENGL_PLATFORM=osmesa it fails to load :

>>> from OpenGL.GL import *  Traceback (most recent call last): File "<stdin>", line 1, in <module> 
File "/usr/lib/python3.6/site-packages/OpenGL/GL/__init__.py", line 4, 
in <module> from OpenGL.GL.VERSION.GL_1_1 import * File 
"/usr/lib/python3.6/site-packages/OpenGL/GL/VERSION/GL_1_1.py", line 14, 
in <module> from OpenGL.raw.GL.VERSION.GL_1_1 import * File 
"/usr/lib/python3.6/site-packages/OpenGL/raw/GL/VERSION/GL_1_1.py", line 
7, in <module> from OpenGL.raw.GL import _errors File 
"/usr/lib/python3.6/site-packages/OpenGL/raw/GL/_errors.py", line 4, in 
<module> _error_checker = _ErrorChecker( _p, _p.GL.glGetError ) File 
"/usr/lib64/python3.6/ctypes/__init__.py", line 356, in __getattr__ func 
= self.__getitem__(name) File "/usr/lib64/python3.6/ctypes/__init__.py", 
line 361, in __getitem__ func = self._FuncPtr((name_or_ordinal, self)) 
AttributeError: /lib64/libOSMesa.so.8: undefined symbol: glGetError

I have tried this on a fedora 27 system and a recent arch linux system. 
It seem like there might have been a change with libOSMesa, or it is 
trying to load the wrong library. Checking the symbols in libOSMesa.so.8 
using "nm -D", I don't see glGetError, or any other similar glGet* 
symbols like what I can see in libGL.so.

Any help much appreciated.

Thanks,

--

Richard





Private Confidentiality:

This email (including all attachments) is intended solely for the named addressee. 
It is confidential and may contain privileged information. 
If you are not the intended recipient, you should not disseminate, distribute or copy this communication. 
If you have received this communication in error, please notify us immediately and delete the original message. 
This email is also subject to copyright. No part of it may be reproduced, adapted or transmitted without the consent of the copyright owner. 

[PyOpenGL-Users] Python & OpenGL for scientific visualization

[Nicolas R. <Nic...@in...>]

Hi all,

I’ve just released an open access book on "Python & OpenGL for scientific visualization”.
It’s not yet fully finished but I think it is already readable.

Website: http://www.labri.fr/perso/nrougier/python-opengl/
Sources: https://github.com/rougier/python-opengl



Nicolas

[PyOpenGL-Users] Tkinter and PyOpenGL via ctypes (no togl)

[Jonathan W. <wr...@es...>]

Hello,

Following up on my troubles with togl I copied some other peoples ideas 
to make a work-around using ctypes and pyopengl to create a context for 
tkinter. It has been very lightly tested on windows and linux/X11. 
Perhaps useful to other people? I would be be very happy if something 
like it could be found in pyopengl (for my own purposes I think I can 
just copy a file into my projects, so don't feel obliged to try to 
maintain/debug this). I put a copy of it here:

https://github.com/jonwright/pyopengltk

It is based on other peoples work [1,2,3]. Feedback is welcome - 
especially if someone has a mac and could get it working there too.

Best,

Jon

===

1: C + Tcl/Tk example: http://github.com/codeplea/opengl-tcltk/ (zlib 
license) and article at: https://codeplea.com/opengl-with-c-and-tcl-tk
2 : Python + Tkinter (no pyopengl) example 
http://github.com/arcanosam/pytkogl/ (The Code Project Open License) and 
article at 
http://www.codeproject.com/Articles/1073475/OpenGL-in-Python-with-TKinter
3: Large regions of code were copied from pyopengl/Tk/__init__.py

Re: [PyOpenGL-Users] glReadPixels not working in thread

[Shir G. <shi...@gm...>]

Thanks a lot!

Actually my goal is to generate data for learning in parallel to the actual
learning process.
So I thought of doing so in another thread.
On Tue, 23 Jan 2018 at 23:10 Ian Mallett <ia...@ge...> wrote:

> ​It's not entirely clear to me your setup. It looks like you're trying to
> use a subprocess? A few things:
>
> - Threads in Python add parallelism, but not performance, due to the
> global interpreter lock. They may even be pure software threads.
> - OpenGL contexts are not threadsafe. It is usually considered an error to
> use OpenGL from multiple threads, although in-principle it can be done if
> the parallel executions correspond to a serial execution, with no overlaps
> (through, e.g., tons of mutexes).
> - Subprocesses definitely will suffer at least that problem. IDR exactly,
> but it may be an error to attempt to share a GL context across
> subprocesses, regardless of any synchronization.
>
> Recommendation: keep all GL calls in one thread, and don't use threads in
> Python anyway unless you need asynchronous operations. If profiling shows
> that OpenGL *command overhead* really is the bottleneck *and* this is
> worth investing effort fixing, move to C++. If you still don't have enough
> performance, move from OpenGL to Vulkan (which unlike GL will allow you to
> build and issue command lists in parallel).
>
> Ian
>