[cairo] Coordinates

[Carl Worth]

On Thu, 01 Dec 2005 16:06:17 +0100, Mirza wrote:
> Would it make sense to create "compatibility option" for how coordinates 
> are interpreted? Most of legacy graphic code I saw assumes that integer 
> coordinates, like (0, 0) are placed in the middle of the pixel, not 
> between pixels. Such global setting (non-default) would make life easier 
> for people switching to Cairo from something else IMO.

Are you suggesting something more elaborate than the following?

	cairo_translate (cr, 0.5, 0.5);

If not, then that option exists already. If so, then I think that
although the idea seems tempting, I also think it's ill-advised.
Primarily because there's no simple operation that will "do what you
want" in all cases.

For example, let's assume cairo's default transformation matrix and
also assume that we're dealing only with axis-aligned, rectilinear
geometry specified with integer coordinates. With these assumptions,
the results that will be achieved depend on the operation performed:

fill:					Crisp, pixel-aligned results
stroke (even integer line width):	Crisp, pixel-aligned results
stroke (odd integer line width):	"Fuzzy", non-pixel-aligned

The (0.5, 0.5) translation above would change this to:

fill:					"Fuzzy", non-pixel-aligned
stroke (even integer line width):	"Fuzzy", non-pixel-aligned
stroke (odd integer line width):	Crisp, pixel-aligned results

So, at the very least, this operation would have to be more complex
than a simple translate, even with all of the simplifying assumptions
we made above. So any attempt to implement a "make my graphics look
good" operation is forced to become a very complex operation that will
in turn be hard for the user to predict/control, which is against the
grain of what cairo tries to provide the user.

Anecdotally, I've heard that Java2D attempted to use a different
half-pixel offset for strokes compared to fills, but eventually
abandoned the idea (with a fair amount of pain).

Finally, at the most fundamental level, the question of doing
pixel-aware alignment ("snapping") is global in nature and cannot be
adequately addressed within cairo's path rendering operations which
have access only to local information.

-Carl

PS. Jonathan Chambers might have some useful insight here as he been
working to try to emulate (non-antialiased) GDI operations as
accurately as possible with cairo. I don't know if he has entirely
succeeded with that yet, but if nothing else, I think he can attest
that the problem is more complex than something like a global
half-pixel offset.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20051201/f5762b46/attachment.pgp