search

landam / grass-gis-git-migration-test

0 stars 0 forks source link

display lib: support for curveto #28

Open landam opened 5 years ago

landam commented 5 years ago

Reported by hamish on 25 Aug 2009 06:04 UTC 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 Dpolyline*() 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)

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/733

landam commented 5 years ago

Comment by glynn on 25 Aug 2009 18:50 UTC Replying to [ticket:733 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 Dpolyline*() 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.

landam commented 5 years ago

Modified by @landam on 12 May 2016 06:44 UTC

landam commented 5 years ago

Modified by @landam on 23 Aug 2016 11:46 UTC

landam commented 5 years ago

Comment by @landam on 27 Aug 2016 13:42 UTC Milestone renamed

landam commented 5 years ago

Comment by neteler on 26 Jan 2018 11:40 UTC Ticket retargeted after milestone closed

landam commented 5 years ago

Modified by neteler on 12 Jun 2018 20:48 UTC

landam commented 5 years ago

Comment by @landam on 25 Sep 2018 16:53 UTC All enhancement tickets should be assigned to 7.6 milestone.

landam commented 5 years ago

Comment by @landam on 25 Jan 2019 21:08 UTC Ticket retargeted after milestone closed