[GRASS-dev] discussion: replacing ps.map

[Dylan Beaudette]

On Friday 06 April 2007 08:06, Glynn Clements wrote:
> Jachym Cepicky wrote:
> > btw: what do you think about replacement of ps.map with new PS driver
> > && d.* commands?
> >
> > would it be easier to add line styles and area fillings to ps.map
> > (where it partely is, at least the areas) or to d.rast/d.vect ? I
> > think, it would be great to have only one set of tools for both - data
> > displaying and hard copy maps preparation...

I still like this approach, however a more seamless method like that used in R 
would be ideal: output is created based on the driver function which is 
called png(), x11(), pdf(), etc. Note that I am not in a position to 
implement this... :( 

> It would certainly be *easier* to change ps.map, as ps.map generates
> PostScript directly.

Would we then be limited to the functionality of ps.map?

> d.* commands are limited to whatever the raster library provides. If
> you want to add an additional operation to the graphics API, you
> currently have to:
>
>  1. Add a R_* function to lib/raster/com_proto.c
>  2. Add its prototype to include/raster.h
>  3. Add a field to "struct transport" in lib/raster/transport.h
>  4. Add an intitialiser for the field to "loc_trans" in lib/raster/com_io.c
>  5. Add an intitialiser for the field to "rem_trans" in lib/raster/com_io.c
>  6. Add a LOC_* version to lib/raster/loc_proto.c
>  7. Add a REM_* version to lib/raster/rem_proto.c
>  8. Add an opcode to include/graphics.h
>  9. Add a "case" to lib/driver/command.c
> 10. Add a COM_* version to lib/driver/<whatever>.c
> 11. Add its prototype to lib/driver/driver.h
> 12. Add a field to "struct driver" in lib/driver/driver.h
> 13. Add a PNG_* version to lib/pngdriver/<whatever>.c
> 14. Add the prototype to lib/pngdriver/pngdriver.h
> 15. Add an intitialiser for the field in lib/pngdriver/Driver.c
> 16. Add a PS_* version to lib/psdriver/<whatever>.c
> 17. Add the prototype to lib/psdriver/psdriver.h
> 18. Add an intitialiser for the field in lib/psdriver/Driver.c
> 19. Add a XD_* version to display/drivers/XDRIVER/<whatever>.c
> 20. Add the prototype to display/drivers/XDRIVER/XDRIVER.h
> 21. Add an intitialiser for the field in display/drivers/XDRIVER/main.c
> 22. Add a NULL intitialiser for the field in display/drivers/HTMLMAP/main.c
>
> If we can eliminate monitors in favour of direct rendering, we can
> eliminate steps 3 through 12. The R_* function would become the COM_*
> function, with no need to dispatch based upon local/remote transport.
>
> If we can eliminate XDRIVER in favour of a GUI which uses PPM/PNG
> images, that loses 3 steps. If we can eliminate the PNG driver in
> favour of "gs -sDEVICE=ppmraw", that loses another 3 (as well as
> giving better quality).

I think that striving for quality would be a good thing. I usually compose 
maps at 2x the resolution and then downscale with the current PNG driver.

> Ultimately, if the PS driver was the only driver, we'd be down to just
> steps 1 and 2. The R_* function would become the PS_* function; there
> would be no need to dispatch based upon the current driver.

If this were the only driver this might solve a couple of issues in a single 
step: high quality on screen output, AND high quality print output. The 
slowness of the PS driver might make working with data more cumbersome, 
however the current monitors are a bit slow anyways...

> More significantly, additional cases wouldn't need necessarily need
> new R_* functions; the module could just generate PostScript code
> directly.

This would be nice if we knew how long it would take to compose the image. 
Here are some more time comparisons for composition of separate RGB channels 
with d.rgb.

region:
rows:       1638
cols:       2160

Xmon
real    0m1.439s
user    0m1.288s
sys     0m0.048s

PNG
real    0m1.419s
user    0m1.288s
sys     0m0.032s

PS
real    0m4.651s
user    0m3.836s
sys     0m0.132s

I also noticed that the PS driver only supports grayscale, perhaps this was 
mentioned previously.

Overall great work Gylnn - this thread has spawned some very interesting 
conversation and development!

Cheers,


-- 
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341