AGG第四十七课 渲染抗锯齿线的宽度问题探讨

系统运维
代码如下：
agg::path_storage path;
for (int i = 100; i < 500; i=i 100)
{
path.move_to(i, 100);
path.line_to(i, 400);
}
for (int ii = 120; ii < 550; ii=ii 100)
{
path.move_to(ii 0.5, 100);
path.line_to(ii 0.5, 400);
}
agg::conv_stroke<agg::path_storage> stroke(path);
stroke.width(1.0);
ras.add_path(stroke);
agg::render_scanlines_aa_solid(ras,sl,renb,agg::rgba8(255,0,0));
分析：不知道你有没有发现浮点坐标渲染的线段似乎更加细，然后似乎深些。可以继续替换
轮廓线宽为0.5，效果一样。当然完全局限于当前的显示屏的分辨率，这就是为什么需要专业
的电脑处理图像的原因。如果线宽设置为1.5，目前暂时没有发现什么不同。
从邮件中分析得出，为什么浮点型0.5渲染的线会颜色深些，这是由于像素实际上是在100和101之间，在这里我对于像素不做过多的定义，假设像素有50%%u5728100点上，50%%u5728101上，这个时候如果移动到100.5如果线宽刚好是1，实际上就是一个完整的像素点，一个完整的矩形，但是如果少了0.5实际上就是横跨两个像素点，这个情况下，实际上就引入了亚像素精度，将像素也就是坐标格子进行了划分，对于坐标格子实际上采用了透明色的处理，之所以没有锯齿，不是因为不存在，而是因为被透明处理了，设置了一定的透明度，使得我们并没有注意到，如果在高分辨率的显示器，还是可以看出来的。
邮件中提及到了，如果渲染横线或者竖线，实际上可以采用低级的渲染器，其中包括render_base,这种情况下，避免了引入亚像素精度，提高了性能，这种情况，在其他的章节会提及。
如下摘录，相关的讨论：
> is the use of copy/blend hline/vline advised for efficiency or for
> better rendering?
only for the sake of performance. and if you need subpixel positioning, you can
draw two adjacent horizontal/vertical lines calculating the intensity according
to the position (i.e, simulating the rasterizer for this simple case) – it will
be more efficient because of excluding some expensive operations.
maxim> actually, if you need to draw horizontal and vertical lines
maxim> of exactly 1 pixel width, always aligned to pixels (say,
maxim> coordinate grid), and if you are absolutely sure you won\\\’t
maxim> need to transform them using agg converters, it\\\’s better to
maxim> use low level renderer_base::copy_hline(), copy_vline(),
maxim> blend_hline(), blend_vline(), or, if you need to draw
maxim> dashed/dotted lines, blend_solid_hspan(),
maxim> blend_solid_vspan(). the latest require an array of
maxim> covers, that can be 0 for gaps and 255 for
maxim> dashes. intermediate values will be drawn with respective
maxim> opacity.
actually, i don\\\’t know that they will be exactly 1 pixel wide (but i
am drawing a coordinate grid so would like to align them to pixels).
i missed that the pixels were aligned to the 0.5 point rather than the
integer point.
is the use of copy/blend hline/vline advised for efficiency or for
better rendering?
> that\\\’s just what i needed to know.
actually, if you need to draw horizontal and vertical lines of exactly 1 pixel
width, always aligned to pixels (say, coordinate grid), and if you are
absolutely sure you won\\\’t need to transform them using agg converters, it\\\’s
better to use low level renderer_base::copy_hline(), copy_vline(),
blend_hline(), blend_vline(), or, if you need to draw dashed/dotted lines,
blend_solid_hspan(), blend_solid_vspan(). the latest require an array of
covers, that can be 0 for gaps and 255 for dashes. intermediate values will
be drawn with respective opacity.
pierre> here you put the line centered exactly on the center of
pierre> the pixels sitting between x=200 and x=201. when painting
pierre> with 1.0 width, you will fill exactly one pixel (at
pierre> x=200).
pierre> so the matter here is not about agg handling ints and
pierre> floats in different ways, just that agg accepts sub-pixel
pierre> positioning, and its anti-aliasing machinery handles it
pierre> quite well.
探讨：尝试修改浮点坐标为整型， 0.5替换为1，发现两根线完全没有什么分别
摘自：http://sourceforge.net/p/vector-agg/mailman/vector-agg-general/?viewmonth=200403
i am drawing some horizontal and vertical paths and notice that the
rasterized line width depends on whether i use an integer or float as
the x coordinate below. i know i can fix this by always passing and
integer

网址怎么购买 如何买到一个好的网址
阿里云服务器ecs如何存储与备份
云空间和云服务器哪个好用
买一个阿里云的服务器后期费用高吗知乎
完美对战平台反作弊加载失败_完美对战平台反作弊启动检测失败解决方法
谷歌浏览器截图快捷键什么谷歌浏览器截图快捷键的两种使用方法
云服务器和独立服务器怎么区分
9类商标