Thread: [PyOpenGL-Devel] Possible bug in PyOpenGL wrapper of glGenTextures?
Brought to you by:
mcfletch
From: Karl K. <sup...@cs...> - 2014-09-08 08:08:54
|
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. |
From: Mike C. F. <mcf...@vr...> - 2014-09-08 13:34:22
|
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 |
From: Karl K. <sup...@cs...> - 2014-09-08 22:32:03
Attachments:
fft_gui_test.py
|
--- OpenGL/GL/exceptional.py Mon Sep 8 15:26:21 2014 +++ OpenGL/GL/exceptional-new.py Mon Sep 8 15:24:24 2014 @@ -182,12 +182,12 @@ """ if count <= 0: raise ValueError( """Can't generate 0 or fewer textures""" ) - elif count == 1 and _configflags.SIZE_1_ARRAY_UNPACK: - # this traditionally returned a single int/long, so we'll continue to - # do so, even though it would be easier not to bother. - textures = constants.GLuint( 0 ) - baseFunction( count, textures) - return textures.value + #elif count == 1 and _configflags.SIZE_1_ARRAY_UNPACK: + # # this traditionally returned a single int/long, so we'll continue to + # # do so, even though it would be easier not to bother. + # textures = constants.GLuint( 0 ) + # baseFunction( count, textures) + # return textures.value else: textures = arrays.GLuintArray.zeros( (count,)) baseFunction( count, textures) |
From: Mike C. F. <mcf...@vr...> - 2014-09-09 13:05:54
|
On 09/08/2014 06:31 PM, Karl Koscher wrote: > Thanks for the quick response. Attached is a simple Python script > which will reproduce the bug without any special hardware. I'm running > gnuradio 3.7.2.2 and PyOpenGL 3.1.0a3 for Python 2.7. AFAIK this is > only a problem on Windows. Here's the traceback: Oh, that's *weird*, apparently the ulong type doesn't work the same way on win32? I'll have to get some time to boot into windows and look into that. Thanks, Mike > TypeError: ("No array-type handler for type <class 'ctypes.c_ulong'> > (value: c_ulong(0L)) registered", > <OpenGL.converters.CallFuncPyConverter object at 0x041F6930>) > > > I've also attached a patch which seems to fix the problem. > > > > On Mon, Sep 8, 2014 at 6:34 AM, Mike C. Fletcher > <mcf...@vr... <mailto:mcf...@vr...>> wrote: > > 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 > > > ------------------------------------------------------------------------------ > 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 > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Devel mailing list > PyO...@li... > <mailto:PyO...@li...> > https://lists.sourceforge.net/lists/listinfo/pyopengl-devel > > -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |