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

[Jean-Denis Giguere]

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