[GRASS5] grass display commands and the osx port

[andy agena]

Hello All:

I'm forwarding the following from a developer who is interested in helping with the GRASS-OS X port.  Any assistance would be appreciated.

Thanks,
Andy Agena

[forwarded message:]

	I'm involved with a project which has the intention of porting GRASS 5 to a new platform. I have gone through the GRASS 5.0 Programmer's Manual and see problems which make it difficult to make a proper port of GRASS 5. I hope you or somebody associated with this project can help.

	The goal of the project is to create what your manual calls a "Specialized Interface" using the multiplatform OpenStep API (same as Apple's "Cocoa" and the free GNUStep project) leveraging the resolution independent graphics abstraction of NSViews (Views can be anything, bezier curves for vector graphics, pixmaps, OpenGL display window, QuickTime movie, etc. NSView is a programmatic interface, not a data structure). The problem is GRASS 5 "Graphics Drivers" are not resolution independent. The drawing routines like draw_line() refer to pixel coordinates.

	This defeats the whole purpose of the port which would support features like resolution independence, layers, 32bit RGBA color (easily converted to CMYK), WYSIWYG printing, anti-aliased vector maps, exporting to Illustrator 9, live zooming, rulers, group selection of vector sets, etc. in a lightening fast manner. My original plan was to create raster and vector Views in their own coordinate system. For example vector maps would be drawn in navigational coordinates while raster images would be drawn in whatever coordinates the cells represented. This would allow the native graphics engine to manipulate the layers and print them in a resolution independent manner (smaller print files and other benefits).

	However I clearly cannot do this with commands like d.rast which first convert the raster image into the display resolution set by the display driver. I hope the reason is obvious.

	I'm not sure how to proceed from here. I'm toying with the idea of creating a set of ns.* commands which mimic the interfaces for the d.* commands so typing ns.rast my_raster_map on the command line will create a new NSImage View. However this sounds like far too much work, I mean doesn't d.rast also have to take projections into consideration?

	I hope somebody knows an alternative. I can't set the display resolution to navigation coordinates or else d.rast will make HUGE bitmaps unnecessarily. I can't do that anyway because the display driver has no knowledge of the resolution of graphics d.rast wants to display in the first place. If d.rast would simply render something where 1 cell = 1 pixel then give the coordinates for the corners I might be able to do something. Perhaps I only have to rewrite all commands which draw raster images them slightly modify all vector drawing commands.

	I'm a tad frustrated trying to work within the X11 mentality which GRASS was apparently written for.

PS: NVIZ on the other hand looks like a much easier port. It doesn't care what resolution OpenGL is rendering to.


---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'