Opened 14 years ago

Closed 13 years ago

#1132 closed task (wontfix)

wxNviz and wxVdigit missing from 6.4svn

Reported by: hamish Owned by: martinl
Priority: critical Milestone: 6.4.2
Component: wxGUI Version: svn-releasebranch64
Keywords: C++ Cc: grass-dev@…
CPU: x86-64 Platform: Linux

Description

Hi,

wxNviz and wxVdigit are missing from 6.4svn in a build using the latest svn. platform is debian/lenny amd64.

CFLAGS="-ggdb -march=amdfam10 -Wall -Werror-implicit-function-declaration" \
  ./configure \
    --with-tcltk-includes=/usr/include/tcl8.5 --with-cairo \
    --with-motif --with-python=/usr/bin/python2.5-config \
    --with-readline --with-cxx --with-odbc --with-sqlite \
    --with-freetype --with-freetype-includes=/usr/include/freetype2 \
    --without-postgres --with-proj-share=/usr/share/proj \
    --enable-64bit --with-pthread \
    --with-wxwidgets=/usr/lib/wx/config/gtk2-unicode-release-2.8 \
    --with-geos \
    2>&1 | tee config_log.txt

...

  Python support:             yes
  wxWidgets support:          yes

...

$ make -j 8
...
--
Errors in:
No errors detected.
--
grass/svn/releasebranch_6_4$ ls dist.x86_64-unknown-linux-gnu/etc/wxpython/
README   gis_set.py    icons/   scripts/  xml/
compat/  gui_modules/  images/  wxgui.py

grass/svn/releasebranch_6_4$ ls gui/wxpython/nviz/OBJ.x86_64-unknown-linux-gnu/
_grass6_wxnviz.so*  grass6_wxnviz_wrap.o  load.o     volume.o
change_view.o       init.o                surface.o
draw.o              lights.o              vector.o

grass/svn/releasebranch_6_4$ ls gui/wxpython/vdigit/OBJ.x86_64-unknown-linux-gnu/
_grass6_wxvdigit.so*  driver_draw.o           message.o   vertex.o
cats.o                driver_select.o         pseudodc.o
digit.o               grass6_wxvdigit_wrap.o  select.o
driver.o              line.o                  undo.o

seems it isn't being installed.

?, Hamish

Change History (10)

in reply to:  description ; comment:1 by glynn, 14 years ago

Replying to hamish:

wxNviz and wxVdigit are missing from 6.4svn in a build

r42875:

Timestamp:
    07/21/10 21:10:11 (4 weeks ago)
Author:
    martinl
Message:
    vdigit + nviz disabled

in reply to:  1 ; comment:2 by hamish, 14 years ago

Replying to glynn:

r42875:

Timestamp:
    07/21/10 21:10:11 (4 weeks ago)
Author:
    martinl
Message:
    vdigit + nviz disabled

I can see wanting to save nviz for a backport of the improved version, but why was vdigit disabled? My experience with it so far on Linux has been very good/impressive.

Hamish

in reply to:  2 comment:3 by glynn, 14 years ago

Replying to hamish:

I can see wanting to save nviz for a backport of the improved version, but why was vdigit disabled? My experience with it so far on Linux has been very good/impressive.

If there are any problems with the vdigit or nviz modules, you lose the whole wxGUI. You can catch an exception; you can't catch a segfault.

And there are so many plausible failure modes. Most of wxGUI will work with any reasonably recent version of Python and wxPython, but the compiled modules will only work with the specific versions they were built against. The binary component is written C++, which tends to be more fragile in terms of binary compatibility.

Finally, a release is bound to get used on a wider variety of systems than the development versions.

Leaving them in might work out, or it might just prove the old adage about "never use a point-zero version; wait for point-one".

comment:4 by hamish, 14 years ago

Milestone: 6.4.06.4.1
Priority: blockercritical
Type: defecttask

in reply to:  2 ; comment:5 by martinl, 14 years ago

Replying to hamish:

I can see wanting to save nviz for a backport of the improved version, but why was vdigit disabled? My experience with it so far on Linux has been very good/impressive.

my motivation was to disable problematic components of wxGUI. The components require specific version of wxPython (copy of pseudodc.cpp/h) and swig. 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+.

Martin

in reply to:  5 ; comment:6 by hamish, 14 years ago

Keywords: C++ added

Replying to martinl:

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? (I guess we can apply our own mere-mortals, already blazed trail, and python ability adjustment factors to that number to get an idea..)

Hamish

in reply to:  6 comment:7 by glynn, 14 years ago

Replying to 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).

comment:8 by martinl, 13 years ago

Cc: grass-dev@… added
Owner: changed from grass-dev@… to martinl
Status: newassigned

comment:9 by martinl, 13 years ago

Milestone: 6.4.16.4.2

comment:10 by martinl, 13 years ago

Resolution: wontfix
Status: assignedclosed

Both components have been ported to Python using Ctypes.

Note: See TracTickets for help on using tickets.