pyopengl-users

[PyOpenGL-Users] PyOpenGL accelerator module

[Eric J. <jo...@MI...>]

Hello! First my apologies if this has been discussed on the list
recently, I couldn't find the relevant sf page for searching the mailing
list archives. 

I'm interested in constructing an openGL-based time series viewer for
some of our tens-of-megabyte time series data, that will work
interactively from python. Matplotlib totally fails when looking at data
of this scale, and the speed of navigation is pretty crucial. 

But I'd like to do as much as possible from python/numpy/scipy, and then
pass the loosly-processed data off to the GPU (i've done a bit of GLSL
work) for visualization. My only concern is that, with its new
ctypes-based bindings, pyopengl3 will be too slow for this sort of
application. 

...Which brings me to the accelerator module -- do people think this
would really be necessary for this sort of app? How much work would it
be to prototype things with the existing pyopengl3 interface and then
"drop in" the accelerator module? I've not been able to find much
documentation about the shape of the eventual module. 

Thanks again, I'm excited to get back to hacking OpenGL !
			...Eric

Re: [PyOpenGL-Users] PyOpenGL accelerator module

[Mike C. F. <mcf...@vr...>]

Eric Jonas wrote:
> Hello! First my apologies if this has been discussed on the list
> recently, I couldn't find the relevant sf page for searching the mailing
> list archives. 
>   
Don't think we've ever discussed it on-list.
> I'm interested in constructing an openGL-based time series viewer for
> some of our tens-of-megabyte time series data, that will work
> interactively from python. Matplotlib totally fails when looking at data
> of this scale, and the speed of navigation is pretty crucial. 
>
> But I'd like to do as much as possible from python/numpy/scipy, and then
> pass the loosly-processed data off to the GPU (i've done a bit of GLSL
> work) for visualization. My only concern is that, with its new
> ctypes-based bindings, pyopengl3 will be too slow for this sort of
> application. 
>   
Actually, that's the use-case where the ctypes bindings tend to be 
irrelevant.  There is a per-array overhead in the bindings to get the 
data-pointer out of the array, but once the data-pointer is retrieved 
it's basically just passing the value directly in to OpenGL.  If you're 
processing huge data-arrays you're likely not going to notice the 
overhead of the data-pointer retrieval, as it will be swamped in the 
real work getting done.
> ...Which brings me to the accelerator module -- do people think this
> would really be necessary for this sort of app? How much work would it
> be to prototype things with the existing pyopengl3 interface and then
> "drop in" the accelerator module? I've not been able to find much
> documentation about the shape of the eventual module. 
>   
It's intended to be an entirely transparent accelerator module.  The 
core code already has hooks for most of the accelerator modules, so it 
will attempt to import from OpenGL_accelerate the various functions that 
are available.  The basic code is already in the bzr/source packages 
with a script called setupaccel.py which builds the package.  Mostly the 
intent is just to extend and debug it to eliminate significant 
hotspots.  Usage will just be to install the accelerator module, no 
changes to code should be necessary.

HTH,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com