add_path内存的使用经验

效率存在于哪里，对于数据库来说，查询的速度就是效率，而最有效的查询

莫过于充分利用索引，遍历全表永远是情非得已！！

道听途说不少，AGG是最高效的，但是也是最搞笑的，高效源自何方！！再高效

的东西，如果不清楚基本的调用方式，一样是白搭！！如下提供了两份代码供其

参考：

for()

{

add_path();

render_scanline();

}

for()

{

add_path()

}

render_scanline();

数据库：

效率的瓶颈是查询的速度

文件读写：

效率的瓶颈是缓存

// It will result in overflow in 16 bit-per-component image/pattern resampling

// but it won't result any crash and the rest of the library will remain 

// fully functional.

虽然会出现溢出，但是不会导致任何的中断，库的其他功能仍正常运行！！Great Job!!but 

How do you do that ? according from red light!!

 while(!agg::is_stop(cmd = dash.vertex(&x,&y)))
    {
      if(agg::is_move_to(cmd))
      {
        mt.add_vertex(x, y,agg::path_cmd_line_to);
      }
      else if(agg::is_line_to(cmd))
      {
        mt.add_vertex(x, y,agg::path_cmd_move_to);
       agg::conv_marker<agg::vcgen_markers_term, agg::arrowhead> arr(mt,ah);
        ras.add_path(arr);
      }
      rensl.color(agg::rgba8(0,0,50));
      agg::render_scanlines(ras,sl,rensl);
      ras.reset();
}

 

如果dash容器的元素个数较多，目前测试发现只要超过831，就会出现agg崩溃的问题，崩溃的现象就是agg无法渲染，所有的效果都变成白色。

解决方案：

猜测是add_path不能够保存太多的路径，所以，必须设置一个阀值，当到达阀值的情况下，开始渲染，在我看来agg的渲染，实际上是将线，通过画刷，描绘到内存中的画布上，采用的是render_scanlines，路径保存的堆栈不足，实际上，add_path添加路线，一次，然后渲染，带来的效率的降低，是否是一个我们不采用该方案的原因，目前没有任何源码阅读的支持。无法搜索这个831是如何计算出来的！！

如下是正确代码：
while(!agg::is_stop(cmd= dash.vertex(&x, &y)))
    {
      if(agg::is_move_to(cmd))
      {
        mt.add_vertex(x, y,agg::path_cmd_line_to);
      }
      else if(agg::is_line_to(cmd))
      {
        mt.add_vertex(x, y,agg::path_cmd_move_to);
       agg::conv_marker<agg::vcgen_markers_term, agg::arrowhead> arr(mt,ah);
        ras.add_path(arr);
        if(count > 800)
{
         rensl.color(agg::rgba8(0,0,50));
         agg::render_scanlines(ras,sl,rensl);
        ras.reset();