[GRASS-dev] Re: [GRASS GIS] #1132: wxNviz and wxVdigit missing from 6.4svn

[GRASS GIS]

#1132: wxNviz and wxVdigit missing from 6.4svn
----------------------+-----------------------------------------------------
 Reporter:  hamish    |       Owner:  grass-dev@…              
     Type:  task      |      Status:  new                      
 Priority:  critical  |   Milestone:  6.4.1                    
Component:  wxGUI     |     Version:  svn-releasebranch64      
 Keywords:  C++       |    Platform:  Linux                    
      Cpu:  x86-64    |  
----------------------+-----------------------------------------------------

Comment(by glynn):

 Replying to [comment:6 hamish]:

 > > wxNviz has been already rewritten in Python (grass65+). Within
 > > the next weeks I am planning to rewrite wxvdigit in Python and
 > > include it in 6.4.1+.
 >
 > just our of curiosity, I wonder the number of programmer-hours it took
 to do that for wxNviz?

 Converting nviz took me a couple of hours, but it's a much, much simpler
 module than vdigit. In particular, the nviz module didn't explicitly use
 wxWidgets at all; it just relied upon the OpenGL context having been set
 up by the Python code.

 Once the ctypes wrappers were generated for the OGSF and nviz libraries,
 the conversion was a direct translation from C++ to Python.

 One of the main issues for vdigit is that it's performing bulk data
 processing, reading individual lines via Vlib and rendering them to a
 PseudoDC. Doing that entirely in Python is likely to be slow, and I don't
 see any easy way around it.

 Using OpenGL would provide more choices.

 One option would be a C (not C++) component which read lines via Vlib and
 "rendered" them into a display list. A C component could be used from
 Python via ctypes, and rendering whole display lists rather than
 individual lines eliminates much of the Python overhead.

 Another option would be utility functions to read large amounts of data
 from Vlib into arrays, which could then be processed using NumPy and
 rendered using glDrawArrays or glDrawElements, so no per-line/per-vertex
 processing in Python.

 Bulk data processing with NumPy is much faster than iterating in Python
 (and NumPy would be an excellent candidate for acceleration via e.g.
 OpenCL or CUDA; I'm surprised it hasn't happened already).

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/1132#comment:7>
GRASS GIS <http://grass.osgeo.org>