[GRASS-dev] numeric-numpy-scipy for graphs?

[John Gillette]

What does "DC" stand for? 

> -----Original Message-----
> From: grass-dev-bounces at grass.itc.it 
> [mailto:grass-dev-bounces at grass.itc.it] On Behalf Of Glynn Clements
> Sent: Monday, April 23, 2007 5:32 AM
> To: Paul Kelly
> Cc: grassgui at grass.itc.it; Michael Barton; Hamish; 
> grass-dev at grass.itc.it
> Subject: Re: [GRASS-dev] numeric-numpy-scipy for graphs?
> 
> 
> Paul Kelly wrote:
> 
> > > In fact, we can do considerably more now with the wxPython (and 
> > > TclTk) drawing commands to than is available in d.graph or 
> > > d.linegraph, even with your nice enhancements.
> > >
> > > In the case of histogramming and profiling, it seems a better 
> > > display to have them come up in a separate window (like 
> is now the 
> > > case with the TclTk profiling module) than have them 
> rendered like a 
> > > map in the main display (like we do now for d.histogram in the 
> > > current TclTk GUI). Rendering maps is complex and it doesn't seem 
> > > efficient to have to go through the same complex 
> procedures to draw 
> > > a histogram or profile that doesn't need to be drawn 
> georeferenced.
> > 
> > Another thought - with the enhancements to the display 
> architecture in 
> > progress/idea stage
> 
> Idea, currently. I need to introduce non-trivial API breakage 
> in order to go much further. Mainly, switching to 
> floating-point coordinates and adding begin/end operations to 
> the move/cont and raster primitives.
> 
> > it might actually be possible to produce better quality graphs for 
> > inclusion in reports/papers etc. using the existing display 
> > architecture. I'm thinking of the move towards PostScript 
> as a display 
> > output format.
> 
> Certainly, I want (decent) PostScript output to at least be 
> an option. 
> 
> The main question is whether we can abandon other formats, i.e. 
> whether modules can rely upon being able to use the full 
> feature set (e.g. arbitrary clip paths, rotation/scaling of 
> all output, pattern fills etc), or whether they will be 
> limited to a common-denominator subset.
> 
> > I imagine with pop-up Windows in the GUI with histograms etc. you 
> > would be limited to printing the thing as a raster graphic 
> at the same 
> > resolution as the screen?
> 
> Not quite. I'm assuming that lines, polygons etc wouldn't be 
> rasterised when using a print DC, but you're still stuck with 
> coordinates on integer boundaries (and a fairly primitive API).
> 
> This is one of the main distinctions between an "ideal" 
> graphics API (PostScript, OpenGL) and an "adequate for GUI 
> use" API (X11, Windows GDI).
> 
> [FWIW, the wx API is heavily based upon Windows' GDI, which 
> hasn't really changed much since Windows 1.0.]
> 
> > Not so good. Unless those
> > new python modules you're looking at perhaps have an option 
> to save as 
> > postscript (I mean proper line-graphics postscript) for printing.
> 
> wx has PostScriptDC and PrinterDC, which allow you to use the 
> same code as for drawing on a screen DC. Not all operations 
> will work on such contexts, e.g. you can't use raster ops 
> (XOR-plotting etc) in PostScript. And you're still limited to 
> the standard DC methods, e.g. 
> no rotated images (NT/2K/XP has this, 95/98/ME doesn't, nor does X).
> 
> > And of
> > course if you use GRASS modules to produce the graphs then as Glynn 
> > says it is also possible to produce them from scripts, 
> which is rather 
> > important. (Rather than having all this functionality tied 
> up in the 
> > GUI and having to re-implement it if we change the GUI).
> > 
> > > For this reason, it seems better to do these kinds of 
> analyses with 
> > > the gui tools, using underlying GRASS modules like 
> r.profile and r.stats.
> > 
> > I agree it "seemed" better/tidier/neater to me at first, but if we 
> > consider the display architecture is being enhanced beyond it's old 
> > clunky state it may not be as logical is it first seemed?
> 
> +1 ;)
> 
> --
> Glynn Clements <glynn at gclements.plus.com>
> 
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>