Re: Possible bug in PyOpenGL wrapper of glGenTextures?
"Mike C. Fletcher" <[email protected]> Mon, 08 Sep 2014 09:34:14 -0400
| Newsgroups | gmane.comp.python.opengl.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============4403765333109279689==
Content-Type: multipart/alternative;
boundary="------------010903060007050102060500"
This is a multi-part message in MIME format.
--------------010903060007050102060500
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
On 09/08/2014 03:48 AM, Karl Koscher wrote:
> I'm running GNU Radio on Windows and was trying to figure out why the
> WX FFT display wasn't working. It looks like glGenTextures(1) is the
> culprit. An argument of 1 is special-cased for
> backwards-compatibility, but this seems to break. Commenting this
> special case out fixes the FFT display.
>
> I think the problem is that a single ulong is passed in to the
> underlying function, but it always expects an array of ulongs. I think
> an array should still be passed in, with the first element of the
> array returned in the special case (instead of the array itself).
>
> Of course, this is all voodoo magic to me, so perhaps there's a good
> reason for the code the way it is. It would be nice for it to work on
> Windows without hacking the code, though.
In ctypes, passing in a <ulong> variable acts as a single-element
*ulong, so that *shouldn't* be the issue. However, it is always possible
that we've got a bug in the handling. Thing is, I can't see anything
wrong with the gnuradio code, and without a traceback or other error to
tell me *what* went wrong, I can't investigate further. I'm assuming
that gnuradio would require a piece of hardware to run, which suggests I
wouldn't be able to reproduce the error easily here.
What would help is:
* report your (gnuradio and) PyOpenGL version
* include a traceback
* include the patch for what you changed to make it work
It *looks* like the wrapper is actually entirely unneeded these days (it
basically duplicates the code in the automated wrapping), but without
knowing *how* the code is failing I can't actually be sure eliminating
the wrapper entirely would fix your problem. From what I can see
gnuradio is only ever calling glGenTextures(1) in a very standard/simple
way.
Take care,
Mike
--
________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.com
http://blog.vrplumber.com
--------------010903060007050102060500
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dwindows-1252"
http-equiv=3D"Content-Type">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-cite-prefix">On 09/08/2014 03:48 AM, Karl Koscher
wrote:<br>
</div>
<blockquote
cite=3D"mid:[email protected]=
ail.com"
type=3D"cite">
<div dir=3D"ltr">I'm running GNU Radio on Windows and was trying to
figure out why the WX FFT display wasn't working. It looks like
glGenTextures(1) is the culprit. An argument of 1 is
special-cased for backwards-compatibility, but this seems to
break. Commenting this special case out fixes the FFT display.
<div><br>
</div>
<div>I think the problem is that a single ulong is passed in to
the underlying function, but it always expects an array of
ulongs. I think an array should still be passed in, with the
first element of the array returned in the special case
(instead of the array itself).=A0</div>
<div><br>
</div>
<div>Of course, this is all voodoo magic to me, so perhaps
there's a good reason for the code the way it is. It would be
nice for it to work on Windows without hacking the code,
though.<br>
</div>
</div>
</blockquote>
<br>
In ctypes, passing in a <ulong> variable acts as a
single-element *ulong, so that *shouldn't* be the issue. However, it
is always possible that we've got a bug in the handling. Thing is, I
can't see anything wrong with the gnuradio code, and without a
traceback or other error to tell me *what* went wrong, I can't
investigate further.=A0 I'm assuming that gnuradio would require a
piece of hardware to run, which suggests I wouldn't be able to
reproduce the error easily here.<br>
<br>
What would help is:<br>
<ul>
<li>report your (gnuradio and) PyOpenGL version</li>
<li>include a traceback</li>
<li>include the patch for what you changed to make it work<br>
</li>
</ul>
It *looks* like the wrapper is actually entirely unneeded these days
(it basically duplicates the code in the automated wrapping), but
without knowing *how* the code is failing I can't actually be sure
eliminating the wrapper entirely would fix your problem.=A0 From what
I can see gnuradio is only ever calling glGenTextures(1) in a very
standard/simple way.<br>
<br>
Take care,<br>
Mike<br>
<br>
<pre class=3D"moz-signature" cols=3D"72">--=20
________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
<a class=3D"moz-txt-link-freetext" href=3D"http://www.vrplumber.com">ht=
tp://www.vrplumber.com</a>
<a class=3D"moz-txt-link-freetext" href=3D"http://blog.vrplumber.com">h=
ttp://blog.vrplumber.com</a>
</pre>
</body>
</html>
--------------010903060007050102060500--
--===============4403765333109279689==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
--===============4403765333109279689==
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-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pyopengl-devel
--===============4403765333109279689==--