Opened 10 years ago

Last modified 8 months ago

#733 new enhancement

display lib: support for curveto

Reported by: hamish Owned by: grass-dev@…
Priority: minor Milestone: 7.6.2
Component: Display Version: svn-trunk
Keywords: Cc:
CPU: All Platform: All

Description

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)

Change History (9)

comment:1 in reply to:  description Changed 10 years ago by 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.
  1. 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.

comment:2 Changed 4 years ago by martinl

Milestone: 7.0.07.0.5

comment:3 Changed 3 years ago by martinl

Milestone: 7.0.57.3.0

comment:4 Changed 3 years ago by martinl

Milestone: 7.3.07.4.0

Milestone renamed

comment:5 Changed 22 months ago by neteler

Milestone: 7.4.07.4.1

Ticket retargeted after milestone closed

comment:6 Changed 17 months ago by neteler

Milestone: 7.4.17.4.2

comment:7 Changed 14 months ago by martinl

Milestone: 7.4.27.6.0

All enhancement tickets should be assigned to 7.6 milestone.

comment:8 Changed 10 months ago by martinl

Milestone: 7.6.07.6.1

Ticket retargeted after milestone closed

comment:9 Changed 8 months ago by martinl

Milestone: 7.6.17.6.2

Ticket retargeted after milestone closed

Note: See TracTickets for help on using tickets.