Re: glReadPixels not working in thread

--===============5810288816825587171==
Content-Type: multipart/alternative; boundary="001a11356ee6703354056377f9ef"

--001a11356ee6703354056377f9ef
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=E2=80=8BIt's not entirely clear to me your setup. It looks like you're try=
ing 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

--001a11356ee6703354056377f9ef
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div style=3D"font-family:times new roman,serif" class=3D"=
gmail_default">=E2=80=8BIt&#39;s not entirely clear to me your setup. It lo=
oks like you&#39;re trying to use a subprocess? A few things:</div><div sty=
le=3D"font-family:times new roman,serif" class=3D"gmail_default"><br></div>=
<div style=3D"font-family:times new roman,serif" class=3D"gmail_default">- =
Threads in Python add parallelism, but not performance, due to the global i=
nterpreter lock. They may even be pure software threads.</div><div style=3D=
"font-family:times new roman,serif" class=3D"gmail_default">- OpenGL contex=
ts 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 exe=
cutions correspond to a serial execution, with no overlaps (through, e.g., =
tons of mutexes).</div><div style=3D"font-family:times new roman,serif" cla=
ss=3D"gmail_default">- Subprocesses definitely will suffer at least that pr=
oblem. IDR exactly, but it may be an error to attempt to share a GL context=
 across subprocesses, regardless of any synchronization.</div><div style=3D=
"font-family:times new roman,serif" class=3D"gmail_default"><br></div><div =
style=3D"font-family:times new roman,serif" class=3D"gmail_default">Recomme=
ndation: keep all GL calls in one thread, and don&#39;t use threads in Pyth=
on anyway unless you need asynchronous operations. If profiling shows that =
OpenGL <i>command overhead</i> really is the bottleneck <i>and</i> this is =
worth investing effort fixing, move to C++. If you still don&#39;t have eno=
ugh performance, move from OpenGL to Vulkan (which unlike GL will allow you=
 to build and issue command lists in parallel).<br></div><div style=3D"font=
-family:times new roman,serif" class=3D"gmail_default"><br></div><div style=
=3D"font-family:times new roman,serif" class=3D"gmail_default">Ian<br></div=
></div>

--001a11356ee6703354056377f9ef--


--===============5810288816825587171==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--===============5810288816825587171==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
PyOpenGL Homepage
http://pyopengl.sourceforge.net
_______________________________________________
PyOpenGL-Users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pyopengl-users

--===============5810288816825587171==--