Hi,
just having a quick look at what is involved with making d.vect's symbol
drawing code into a library function.
-- sorry about the mess, a few issues here.
I notice that d.vect's plot1.c uses G_plot_polygon():
/* Note: it may seem to be strange to calculate coor in pixels, then
convert to E-N and plot. I hope that we get some D_polygon later. */
Were the ones in the raster lib just missed (R_polygon_abs(), etc.), or is
there another reason to do it this way?
e.g., when to use:
D_move_abs(x,y)
D_cont_abs(x,y)
and
R_move_abs(x,y)
R_cont_abs(x,y)
??
We could do D_() wapper fns for the other R_() fns, but is there a
point? Does clipping matter? If it does, make wrapper fns as needed?
Do we want a D_symbol() fn to be clipped (speed up plotting of LIDAR data)?
I finally realize that the raster lib has nothing to do with raster maps,
only rasterized drawing to the display.
---
To get a symbol drawing lib fn working I've called it S_plot(), not
D_symbol():
int S_plot(SYMBOL *Symb, int x0, int y0, SYMBCOLOR *line_color, SYMBCOLOR *fill_color)
as I don't want the display lib to have to depend on the symbol.h header.
Or is that ok? (size, rotation are taken care of by S_stroke().)
any clean way to get/save current RGB color from the driver?
Currently the code is working, but too ugly to live.
---
in lib/gis/plot.c:
/* NOTE (shapiro):
* I think the adding of 0.5 in slowline is not correct
* the output window (left, right, top, bottom) should already
* be adjusted for this: left=-0.5; right = window.cols-0.5;
*/
.. for plot((int)(x+0.5), (int)(y+0.5)) style rounding.
so is all the (int)(x+0.5) stuff the in display modules wrong?
this stuff makes my head hurt.
---
lib/display/draw.c: are the comments to D_set_clip_window() wrong?
* Sets the clipping window to the pixel window that corresponds
- * to the current database region. This is the default.
+ * to the given display pixel coordinates.
thanks for any hints,
Hamish