renderer_base低级渲染器应用的时机

1 前言

摘自：http://sourceforge.net/p/vector-agg/mailman/vector-agg-general/?viewmonth=200403

    该话题是由于讨论整型和浮点型的线宽之间的差异，从而引出的低级渲染器的出现时机，实际上主要是考虑到性能。

2 翻译

实际上，如果需要渲染1个像素宽度的横线或者竖线，通常和像素对齐，就是占满坐标格子）实际上，如果确定不需要使用AGG的任何转换，最好使用低级的渲染器render_base.

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.

John Hunter wrote:
> 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 (but this causes other complications), but am wondering if
> this is the desired behavior, and if there is some bit of agg magic
> that will display the lines with the same thickness even if the x
> coords are sometimes integers, sometimes floats.

[...]

>   path.move_to(100, 100);
>   path.line_to(100, 400);

Imagine that your screen is a set of small squares which I will call
"pixels" below (I'll let others define exactly what "pixel" means).

The vertical line is centered on the boundary between the pixels
at x=99 and x=100. With a width of 1.0 pixel, you'll have 50% pixel
coverage at x=99, and 50% pixel coverage at x=100.

Two pixels get drawn using half the opacity.

>   path.move_to(200.5, 100);
>   path.line_to(200.5, 400);

Here you put the line centered exactly on the center of the pixels
sitting between x=200 and x=201. When painting with 1.0 width, you
will fill exactly one pixel (at x=200).

So the matter here is not about AGG handling ints and floats in
different ways, just that AGG accepts sub-pixel positioning, and its
anti-aliasing machinery handles it quite well.