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?
Thanks.
Huidae Cho
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, y2If 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@gclements.plus.com>
The reason why I asked this is that descriptions in lib/raster/protocol.c
confused me and I thought this can be also misleading others.
On Thu, Feb 16, 2006 at 03:53:35PM +0000, Glynn Clements wrote:
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.
I got your point. Then the following sequence should isolate the box from line
(10, 10) -- (20, 20).
R_move_abs(10, 10);
R_cont_abs(10, 10);
R_box_abs(WHATEVER);
R_cont_abs(20, 20);
Then, we have to correct comments above R_(box|polygon)_* definitions. If I'm
right, would you please?
Thank you.
Huidae Cho
--
Glynn Clements <glynn@gclements.plus.com>
Huidae Cho wrote:
> OTOH, it's not fine for a client to rely upon any specific behaviour
> regarding what those functions do to the current point.I got your point. Then the following sequence should isolate the box from line
(10, 10) -- (20, 20).R_move_abs(10, 10);
R_cont_abs(10, 10);
R_box_abs(WHATEVER);
R_cont_abs(20, 20);
The final R_cont_abs() doesn't make sense. There should always be an
R_move_abs() between any box or polygon function and any R_cont_*() or
R_*_rel() function.
Then, we have to correct comments above R_(box|polygon)_*
definitions.
Yes.
If I'm right, would you please?
Done.
--
Glynn Clements <glynn@gclements.plus.com>