[cairo] Cairo developers conference call 2004-10-19 18:00 UTC

[Andrew Johnson]

On Mon, 2004-10-18 at 01:09 +0100, Paul Sladen wrote:
> > I do not believe there is any desire for aliased diagonal lines or fonts, as 
> > they look like crap when compared to the aliased output.
> 

> Users (developers) are not stupid.  If the user (developer) wants something,
> it is Cairo's job to provide it---not question their need.

I definitely agree with this, and that has been my primary concern with
this several times repeated topic, too presume there is no use
whatsoever for aliased lines is to also limit what MIGHT be done with
them, simply because you can't think of any good reason yourself.

I can think of one good example of the flaws in Cairo always
anti-aliasing simply with toolkits and themes - widget edges.

A radio button in a traditional theme is an inset beveled circle of some
sort, produced by alternating arcs. Usually you have 4 arcs of
alternating colours. With Cairo this means you have to draw arc 1, set
colour/line thickness, stroke, draw arc 2, set colour/line thickness
stroke. etc. What this produces is overlapping Anti-Aliasing which
causes a loss of definition which instead of creating a sharply defined
edge, causes a soft subtler edge. This isn't always a BAD thing,
however, it does limit what can be done in terms of thematic elements,
which is a subject that definitely should be considered as many people
are looking at using it for toolkit back-ends.

One Solution too this would be too presume the concept of an anti-alias
pass, or if you could draw multiple coloured lines within the same
"stroke", to cause a consistent AA across the entire edge, but its not
that simple, so the ability to have NO AA at all is also a valid
solution to this, and in some cases just as desirable. On for example
the perfectly square edges on widgets  with all vertical/horizontal
lines, AA again even without overlapping lines causes a loss of
definition no matter HOW good its applied creating a softer look yes,
but also less defined edges.

Sure these issues might be partly avoided with far more advanced
programming, but traditionally, if you want simple lines on screen, you
draw simple lines on screen, no transforms, no matrices, no filters, no
advanced calculations. Having to deal with such potential complexities
for such a traditionally simple task is imo a step backwards in terms of
usable screen rendering API.

Just my 2 cents.


-- 
Andrew Johnson <acjgenius at earthlink.net>