[GRASS5] Proposal for GRASS UI roadmap

[Glynn Clements]

Michael Barton wrote:

> > Making OpenGL a mandatory requirement could be problematic, i.e. it
> > could result in a significant proportion of potential users being
> > unable to use GRASS.
> 
> OpenGL seems to be becoming increasingly crucial for complex
> visualization--including 3D--and such visualization is becoming increasingly
> important for GIS and related spatial technologies. It also seems to be
> better supported both in hardware and software.
> 
> Nevertheless, it is a good idea to keep GRASS as useable as possible for the
> broadest possible user base--especially given its popularity
> internationally. 
> 
> This raises 2 questions to me:
> 
> 1. Could a display window function without OpenGL in 2D mode, then call
> OpenGL IF the 3D mode was invoked? That way, people without OpenGL could use
> all the display functions except the 3D mode (much like now when running
> NVIZ is not required for standard display).

Yes; however:

First, there's the issue of being able to compile the application in
the first place on a system which lacks a working OpenGL library and
headers.

It's not uncommon for systems to end up with a broken OpenGL
installation due to conflicts between an OpenGL implementation
supplied by the hardware vendor (ATI, nVidia) and the base operating
system or X11, or conflicts between native and X versions of OpenGL on
Cygwin or MacOS X.

Second, once the application is compiled, any given X server may or
may not implement the GLX extension. Just because an application was
compiled with OpenGL support, it doesn't mean that it will work at run
time.

My point is that OpenGL needs to be treated as an optional feature.
Someone who can't compile or run OpenGL apps should still be able to
use any functionality which doesn't inherently require OpenGL.

> 2. Is there an alternative to OpenGL for rendering 2.5D and 3D imagery that
> would work as well but be useable for a wider group of users?

No. For anything beyond 2D graphics, OpenGL is the most portable
option.

> >> DISPLAY CONTROL GUI AKA GIS MANAGER
> >> 
> >> We should keep single display control (like current GIS Manager). distinct
> >> from the  display window(s). This allows for multiple display windows to be
> >> controlled from single interface. Display "commands" should be integrated
> >> into display control interface; there would be no separate d.* command
> >> modules. That is, the display control system should be able to directly draw
> >> graphics to a display window, without going through intermediate, stand
> >> alone programs. We need to rethink how these would best be implemented
> >> (e.g., should we combine thematic vector and chart display functions?)
> >> Display functions should still be scriptable as in nviz and d.m, just not
> >> independent "commands". It should be possible to run a display script from
> >> the command line to automate mapping.
> > 
> > The main problems with monolithic applications are reliability and
> > memory leaks. Having d.rast crash is less serious than having your
> > monolithic application crash.
> 
> It also depends on how 'monolithic' the application is. I think most people
> want most of GRASS to stay modular. However, there seem to be important
> advantages to building display functions into the UI.

Such as?

There are advantages to building interactive functions (e.g. d.what.*
and similar) into a monolithic UI, but I'm unaware of any reasons to
build in output-only modules such as d.rast.

That doesn't meant that there definitely aren't reasons, just that I
haven't heard any.

-- 
Glynn Clements <glynn at gclements.plus.com>