[GRASS5] current position

[Glynn Clements]

Huidae Cho wrote:

> According to lib/raster/protocol.c ALL R_*_(abs|rel) function should update
> cur_x and cur_y in the display driver, but I found some routines don't:
> 
> R_polydots_*:	updated to the last point
> R_polyline_*:	updated to the last point
> R_polygon_*:	NOT updated => should be the first/last point
> R_box_*:	NOT updated => should be x2, y2
> 
> If R_polygon_*/R_box_* update the current position, is there any side effect?

Who knows? I don't, and I've probably spent more time than anyone else
analysing the detailed behaviour of the display architecture over the
last few years.

To be safe, every "complete" sequence of operations should be assumed
to leave the current position undefined; R_move_abs() is cheap.

By "complete", I mean anything other than R_{cont,move}_{abs,rel},
which are designed to be used as "steps" in a sequence, where you have
to rely upon the current position being updated correctly.

The behaviour which you've listed above basically makes sense. You
might reasonably split polydots/polyline operations into sub-stages
(given a series of points/lines, you should be able to draw them all
in one go or in stages, with the same result regardless), but the same
isn't true for a filled polygon or box.

Certainly, nothing is relying upon the polygon/box functions updating
the current point; if it was, we would have noticed by now.

IOW, it's fine if the box/polygon cases stay the same, it's fine if
they are changed to use the last point, it's even fine if they are
changed to set the current position to some random point.

OTOH, it's not fine for a client to rely upon any specific behaviour
regarding what those functions do to the current point.

-- 
Glynn Clements <glynn at gclements.plus.com>