display lib: support for curveto

[hamish]

Hi,

it would be nice if the display library had a D_curve_abs() and D_curve_rel() functions to handle Bezier Curves. Among other things this would make displaying EPS/SVG/DXF graphics directly on the display monitor/canvas/whatever you want to call it now a whole lot easier. I am not sure if it is better to expose a variable to control the number of vertices along the line to be produced, or for the display lib to decide that dynamically. I assume the coord input needs would be 3 or more pairs of coords. Again, not sure if either be like D_polyline_*() and require a "int n" argument or just have it loop while coord[] != NULL.

In the short term it could immediately be added to d.graph as a new curve instruction and as a demonstration/testbed. (See the LIMITATIONS section of the d.graph man page) I expect the cairodriver and psdriver could use it directly, but not sure of GIS uses for it beyond decorations. Hmmm... new line drawing tool in wxVdigit?

thanks, Hamish (who has just spent more time than I care to calculating vertices by hand)

[glynn]

Replying to hamish:

it would be nice if the display library had a D_curve_abs() and D_curve_rel() functions to handle Bezier Curves.

Are you volunteering to update the clipping/culling code to handle Bezier curves?

Among other things this would make displaying EPS/SVG/DXF graphics directly on the display monitor/canvas/whatever you want to call it now a whole lot easier. I am not sure if it is better to expose a variable to control the number of vertices along the line to be produced, or for the display lib to decide that dynamically. I assume the coord input needs would be 3 or more pairs of coords. Again, not sure if either be like D_polyline_*() and require a "int n" argument or just have it loop while coord[] != NULL.

Are you planning on having the application supply explicit control points, or have the display library determine the tangents itself?

For the former, an open path with N segments requires 3N+1 vertices (versus N+1 for a polyline), while a closed path requires 3N (versus N). For the latter, the number of vertices remains unchanged.

I expect the cairodriver and psdriver could use it directly, but not sure of GIS uses for it beyond decorations. Hmmm... new line drawing tool in wxVdigit?

None of the drivers can use anything directly, because:

1. Some people want to be able to pass non-Euclidean geometry directly to the display library, but none of the underlying graphics libraries or formats support that, so the display library has to "euclidify" the data.

2. Some people want the display library to clip/cull the data to the current region, because letting the driver render the entire map is too much work for the driver, and having the module clip/cull the data to the current region is too much work for the module's author, so the display library has to clip/cull the data.

[martinl]

Milestone renamed

[neteler]

Ticket retargeted after milestone closed

[martinl]

All enhancement tickets should be assigned to 7.6 milestone.

[martinl]

Ticket retargeted after milestone closed

[martinl]

Ticket retargeted after milestone closed