[GRASS5] grass display commands and the osx port
Eric G. Miller
egm2 at jps.net
Mon Feb 26 21:29:39 EST 2001
On Mon, Feb 26, 2001 at 02:12:01PM -0600, andy agena wrote:
> [forwarded message:]
> 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'
More information about the grass-dev