Anti-Grain Geometry (Historical)

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.


    Pierre

>>>>> "Pierre" == Pierre Arnaud <pierre.arnaud@...> writes:

    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.

Thanks Pierre,

That's just what I needed to know.

JDH

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

McSeem


__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com

>>>>> "Maxim" == Maxim Shemanarev <mcseemagg@...> writes:

    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?

Thanks,
JDH

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


__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com