[GRASS-dev] [GRASS GIS] #1719: GRASS 7 Monitor command line support

GRASS GIS trac at osgeo.org
Tue Sep 4 02:24:49 PDT 2012


#1719: GRASS 7 Monitor command line support
-------------------------+--------------------------------------------------
 Reporter:  annalisapg   |       Owner:  grass-dev@…              
     Type:  enhancement  |      Status:  new                      
 Priority:  normal       |   Milestone:  7.0.0                    
Component:  wxGUI        |     Version:  svn-trunk                
 Keywords:  d.mon        |    Platform:  Unspecified              
      Cpu:  Unspecified  |  
-------------------------+--------------------------------------------------

Comment(by wenzeslaus):

 Even if we have people, time or money to develop another (simpler, faster)
 version of GUI, I think that this would be wasting resources.

 But I understand the pressure for second GUI. To my knowledge there are
 several problems with the wxGUI which are difficult to over come:
  * it is in Python and simple loop is always slower in Python then in
 C/C++
  * loading of dynamic (wxWidgets, wxPython) libs and modules always takes
 some time, when you open display/GUI for the first time (when I'm opening
 the second display it is much faster)
  * rendering to files and then displaying this files on screen is slower
 than direct drawing of data to screen

 About the last point, we are using rendering to files because
 displaying/drawing of maps is done by modules, not library functions, and
 moreover, it is not safe to call functions from GUI since they call
 G_fatal() which calls exit(), right?

 However, the situation is not so bad. Considering current state, the
 rendering can be improved at least in two ways:
  * change the PPM files to something compressed (see
 [http://lists.osgeo.org/pipermail/grass-dev/2012-August/059099.html ML])
  * use different rendering engine for (big) GUI and for (wx) monitors.
 This engine could use library functions and can call exit() because it
 would end only one monitor, not the whole GUI. But there are two problems.
 The first is mirroring of display architecture provided by modules and the
 second is maintenance of additional code (but this can be only minor issue
 if it is well designed)

 Then I got impression that there is some issue with PNG driver (if we want
 to use it instead of PPM) and also that cairo driver could help but it is
 not ready.

 I haven't studied this monitor/display topic and I can be wrong, please
 correct me if so.

 However, I'm pretty sure that for some things mentioned above and for
 enabling wxGUI functionality to wx monitors heavy GUI code refactoring is
 necessary. The place to start is mapdisp package as martinl mentioned. I'm
 very interested in this refactoring but currently I have no time for it.
 But at least we can start to discuss it.

 Considering GUI development, I think that GUI code refectoring is what we
 should spend time with, not the second GUI. After refactoring we can get
 some new features much more easily and also the maintenance can be easier.

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/1719#comment:8>
GRASS GIS <http://grass.osgeo.org>



More information about the grass-dev mailing list