[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