Hi everyone,
I would like to do some experimentation with graphic driver. In GRASS programmer manual, we can read that there is a directory called GENERIC that contains basic routines. I can't find this direction in 5.3 nor 5.7 cvs tree.
Does someone know where can I find it ? Is there a new alternative to start a driver ?
I would like to try to write a driver that would be a gtk widget and use it in gtkGRASS. Does it make sense ?
Thank you !
Jean-Denis
Jean-Denis Giguere wrote:
I would like to do some experimentation with graphic driver. In GRASS
programmer manual, we can read that there is a directory called GENERIC
that contains basic routines. I can't find this direction in 5.3 nor 5.7
cvs tree.Does someone know where can I find it ?
It doesn't exist in 5.0/5.3/5.7; it exists in 4.3.
Is there a new alternative to start a driver ?
The common code is in src/display/devices/lib (5.0/5.3) or
display/drivers/lib (5.7). The closest thing to a generic driver is
the PNG driver, which essentially renders to a block of memory which
is then written out as a PNG file when the driver terminates.
I would like to try to write a driver that would be a gtk widget and
use it in gtkGRASS. Does it make sense ?
The closest existing driver would be XDRIVER.
Note that you can force XDRIVER to use an existing X window by setting
the environment variable XDRIVER_WINDOW to the window's XID. However,
it does require almost exclusive use of the window which it is given;
in particular, the creator must not attempt to redraw the window or
change its background pixmap. Also, if the creator selects ButtonPress
events, the mouse handling functions (Get_location_with_*) won't work
(although you may prefer to have the application handle that
directly).
Personally, I would consider making gtkGRASS render PNG images using
PNGdriver, and have the application just display those images. That
would allow layers to be hidden/shown instantaneously, and
individually redrawn, rather than having to redraw the entire stack
every time that something changes. It would also allow you to have
translucent layers (using e.g. gdk_pixbuf_composite()), which can't
readily be implemented with the existing display architecture.
More generally, the existing display architecture is long past its
prime; it was originally designed in the era of graphics terminals
like the Tek 4105, and it shows. If you're planning on writing a real
GUI for GRASS (as opposed to a hack like tcltkgrass or d.dm), you
would be better of avoiding the existing display architecture, IMHO.
Not only is it extremely limited, but it isn't particularly efficient
either.
--
Glynn Clements <glynn.clements@virgin.net>
Glynn Clements wrote:
Jean-Denis Giguere wrote:
I would like to do some experimentation with graphic driver. In GRASS programmer manual, we can read that there is a directory called GENERIC that contains basic routines. I can't find this direction in 5.3 nor 5.7 cvs tree.
Does someone know where can I find it ?
It doesn't exist in 5.0/5.3/5.7; it exists in 4.3.Is there a new alternative to start a driver ?
The common code is in src/display/devices/lib (5.0/5.3) or
display/drivers/lib (5.7). The closest thing to a generic driver is
the PNG driver, which essentially renders to a block of memory which
is then written out as a PNG file when the driver terminates.I would like to try to write a driver that would be a gtk widget and
use it in gtkGRASS. Does it make sense ?
The closest existing driver would be XDRIVER.Note that you can force XDRIVER to use an existing X window by setting
the environment variable XDRIVER_WINDOW to the window's XID. However,
it does require almost exclusive use of the window which it is given;
in particular, the creator must not attempt to redraw the window or
change its background pixmap. Also, if the creator selects ButtonPress
events, the mouse handling functions (Get_location_with_*) won't work
(although you may prefer to have the application handle that
directly).Personally, I would consider making gtkGRASS render PNG images using
PNGdriver, and have the application just display those images. That
would allow layers to be hidden/shown instantaneously, and
individually redrawn, rather than having to redraw the entire stack
every time that something changes. It would also allow you to have
translucent layers (using e.g. gdk_pixbuf_composite()), which can't
readily be implemented with the existing display architecture.More generally, the existing display architecture is long past its
prime; it was originally designed in the era of graphics terminals
like the Tek 4105, and it shows. If you're planning on writing a real
GUI for GRASS (as opposed to a hack like tcltkgrass or d.dm), you
would be better of avoiding the existing display architecture, IMHO. Not only is it extremely limited, but it isn't particularly efficient
either.
In not sure that I am yet the best person to rewrite graphic driver from scratch. But, if my experimentation may be useful, I will please to work on this.
If you don't use the the current display architecture, at which level would you start your work ? Raster Graphics library ? Somewhere else ?
Which improvements are recquire to have a very good graphic display tool ?
Thank you again,
Jean-Denis
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@virgin.net>