[GRASS-dev] Re: [GRASS GIS] #733: display lib: support for curveto

[GRASS GIS]

#733: display lib: support for curveto
--------------------------+-------------------------------------------------
  Reporter:  hamish       |       Owner:  grass-dev at lists.osgeo.org
      Type:  enhancement  |      Status:  new                      
  Priority:  minor        |   Milestone:  7.0.0                    
 Component:  Display      |     Version:  svn-trunk                
Resolution:               |    Keywords:                           
  Platform:  All          |         Cpu:  All                      
--------------------------+-------------------------------------------------
Comment (by glynn):

 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
 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.

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/733#comment:1>
GRASS GIS <http://grass.osgeo.org>