vector/antialiasing inaccuracy

[jlous]

[PDN 3.31]

There is something strange with he vector rasterizer:

When drawing ellipses or diagonal lines with antialiasing on,

it is impossible to get a symmetrical result. Circles for example,

tend to be slightly heavier downwards and to the right.

To reproduce:

- use an even white background for best effect

- zoom in a lot (800% or so)

- select ellipse tool and turn on anti-aliasing

- draw a tiny black circle, for exanple 6 pixels across.

- Notice how no four 'sides' or corners' are alike.

Similarly, you cannot make a 45-degree line that is

symmetrical about its own centerline, regardless of line thickness.

I use PDN a lot for making small web graphics elements.

This kind of thing is annoying and unprofessional-looking enough

that I often resort to clunky workarounds like copying and

flipping to get it pixel-perfect. But this really shouldn't be necessary.

[RyuinfinityPDN]

Really?

EDIT: All look the same for me.

[ncfan51]

Are you holding down shift? They look the same for me too.

[jlous]

Not holding shift.

Screenshot:

It's subtle, but for example the top row of the circle is significantly lighter than the bottom row, the inner 4 pixels are all different, and the diagonal is clearly not symmetrical.

Is this not happening on other peoples' installations?

[Ash]

Yes, I tried it, it's the same as your screen shot.

A workaround for now, just use :AntiAliasingOff: for the lines and use feather or blurs after.

[jlous]

An even better workaround is work at a larger scale (clean multiple) with :AntiAliasingOff:, and resize down afterwards.

It is still a pity though: The reasterizer itself seems to be probably very good, supoprting sub-pixel precision and everything. PDN doesn't realize the whole potential of that, since there are no sub-pixel control over the drawing tools, restricting you to discrete pixel positions. But that's very understandable and not much of a loss for most work.

But when it does enforce snapping to integer pixel positions, I wish it would do it right, thereby at least offering the same level of functionality as a non-subpixel rasterizer.

[jlous]

Sneaking suspicion: is there a small constant being added somewhere, just to avoid having to deal explicitly with zero-extent cases?

[Mike Ryan]

If anything this would have to be a GDI+ issue and thus out of the hands of Rick.

Or, I can just *cough*

[jlous]

It does indeed seem to be a GDI+ problem. My own toy program displayed exactly the same issue.

The positioning in GDI+ seems to be totally batmanure crazy, with no discernible pattern in the oddities either. I managed to produce something a lot closer to (but not quite) uniform circles by adding these seemingly arbitrary offsets:

void HackedEllipse(Graphics g, Pen p, float x, float y, float width, float height)
{
 g.DrawEllipse(p, x-0.1f, y-0.15f, width, height);
}

God only knows where those numbers come from, but it seems to work reasonably well independently of position, line width and diameters.

This hack is of course entirely implementation dependent. But GDI+ doesn't seem to rev very often, so it might be worth it.

Also, there are many other people have noticed the peculiarities of GDI+, and there are several replacement libraries or other fixes out there. Here's one http://www.codeproject.com/KB/GDI-plus/ ... ssues.aspx

[jlous]

BTW, the same offsets seem to similarly improve DrawLine as well (applied to both endpoints)

[Rick Brewster]

I hate GDI+.

[BoltBait]

...hard to argue with its speed, though.

[LFC4EVER]

GDI+ :? :shock:

What is it?

[BoltBait]

GDI+ :? :shock:

What is it?

You really should ask Wiki before posting in a public forum.

http://en.wikipedia.org/wiki/GDI%2B