[GRASS5] New display architecture for GUI [was: can't find GENERIC graphic driver in cvs trees]

[Glynn Clements]

Jean-Denis Giguere wrote:

> If you don't use the the current display architecture, at which level 
> would you start your work ?  Raster Graphics library ? Somewhere else ?

One option would be to take the code for the most important display
components (d.rast, d.rgb, d.vect etc), replace the use of the raster
and display (R_* and D_*) functions with GDK calls, and incorporate
the result directly into the application.

With that approach, you wouldn't be limited by the (rather primitive)
display API. E.g. you could use dashed lines, "thick" lines (lines
wider than a single pixel), stipple patterns, TrueType fonts etc, none
of which are supported by the existing display architecture.

Another issue: the way in which the raster library does colour
management is less than ideal. For a start, most operations use a
colour palette, even on 24-bpp displays. Defining a palette with
16777216 colours isn't feasible (although it's possible), so
D_set_colours() creates a 32x32x32 colour cube palette (which
corresponds to a 15-bpp display).

It's possible to bypass this using the RGB raster functions
(D_set_colors_RGB, D_draw_raster_RGB etc), but d.rast uses the
original (paletted) interface, which can result in visible banding.

Yet another issue: the display library rescales rasters to fit the
current monitor frame. The raster which is being rescaled will
possibly have already been rescaled from its original resolution by
the libgis raster I/O functions. It would be better to set the current
region to match the monitor (i.e. one cell equals one pixel) so that
the raster was only rescaled once, but then you would need to save and
restore the current region.

If you were doing the rendering in the application rather than calling
e.g. d.rast, you would just set the region internally, and wouldn't
need to set the persistent region (the WIND file).

Having said all of that, one advantage of having separate programs
(d.*) is that, if an operation results in a crash, it will only crash
the individual program rather than the entire GUI application.

-- 
Glynn Clements <glynn.clements at virgin.net>