[GRASS5] grass display commands and the osx port

[Eric G. Miller]

On Mon, Feb 26, 2001 at 02:12:01PM -0600, andy agena wrote:
> [forwarded message:]
> 
[snip...]
> 	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.

Because you can't...

> 	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.

Actually, I think the display/raster interface was designed well before
anyone standardized on X.  I don't think there's much that can be done
about it, except to essentially start from scratch.  The X11 mentality
isn't bad (Event Driven, Client/Server, Network Transparent).  From what
I can tell, most of the popular GUI toolkits provide a higher level
abstraction for drawing than Xlib (which is really only meant to be a
starting point for toolkits/widgets).  The GRASS display/raster
interface was designed for painting pixels on dumb monitors with a
backend driver supporting the particular hardware.  For that, it works
well.  But clearly, it is not an appropriate interface for designing
highly interactive GUI's.

-- 
Eric G. Miller <egm2 at jps.net>

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