[cairo] Antialiasing and round, bevelled widgets (was: Cairo developers conference call...)

[Andrew Johnson]

On Mon, 2004-10-18 at 17:40 -0400, Carl Worth wrote:
> > I can think of one good example of the flaws in Cairo always
> > anti-aliasing simply with toolkits and themes - widget edges.
> 
> What's the flaw here?
>

It limits what I can do with Cairo, in fact ensuring that as long as I
desire to draw certain things I will not be able to use Cairo, something
I find very objectionable as in most other ways Cairo offers the best
solutions to an all purpose drawing api.

> > 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.
> 
> Have you actually tried this and found it objectionable?
> 

yes and sort of.

I do not find the result objectionable in itself. but it doesn't match
the desired output, I can in fact make the square edges mostly what I
want doing as in your example, something I figured out on my own a long
while ago, but applying it to curves never fully works.

> I will admit that there is some error accumulation as multiple objects
> pile up on the same pixels with each object being antialiased
> independently. But that kind of error is much, much smaller than the
> errors from not performing antialiasing at all.
>
> I just augmented cairo-demo/png/bevels.c to include round objects
> similar to the previous squares. I've attached the resulting image.
> 
> I won't bother attaching the code again. The only interesting part is
> carefully computing the circle centers and radii. As before, the value
> 0.5 figures prominently.
> 
> But, take a look at the attached figure. Do you find it objectionably
> soft? To my eye, the circular bevels match the rectangular ones quite
> nicely. The rectangular versions are pixel-precise with respect to the
> corresponding non-antialiased versions. And I think the circular
> versions here look quite a bit better than their corresponding
> non-antialiased versions.
> 

I don't find it "objectionably" soft, but I do find it imprecise. And
again, sometimes this isn't the type of appearance being attempted to
achieve.

I am kind of confused in this as I think your example demonstrates the
problem, the round edge is _not_ as precise or as sharp as your square
edges and I find this to be very obvious. Sure your edge looks nicer
then certain radio buttons I have seen, but even compared to the win32
button, there are several minor discrepancies which prevent the bevel
from being as seamless, in fact given your example, I would prefer the
Windows Aliased way, then your way, simply so it would properly blend
with the square controls, which shouldn't be the case.

> > 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.
> 
> I don't think that the code I wrote today used any "advanced
> programming". I just used a little graph paper to count out the
> adjustments I needed. Someone smarter than me could have put the 0.5's
> in the right places with less work.
> 

Advanced persay, no, but certainly not expected, nor completely
comprehensible, especially as it doesn't work scalably, which DOES add
cumbersome additional code to handle it arbitrarily. Something I already
ran into when attempting to do this sort of thing.

> That said, I do want to consider ways to do this kind of pixel alignment
> within cairo. The huge advantage that would bring is that the graphics
> would work at arbitrary scales.
> 

This would naturally be ideal.

> And, as I said before, I don't think that widget styles as in the
> attached screenshot are an interesting way forward. Rather than drawing
> two, pixel-wide lines in opaque paint, a much more interesting bevel
> should be possible by blending a translucent gradient over a
> background. That style would work over arbitrary backgrounds, would be
> more naturally scalable, and could help free UI designers from
> artificial rectilinear constraints.
> 

I think here we reach part of the problem, I agree that this type of
bevel would be interesting and in some ways superior to deal with, but I
think it ignores the problem. Telling me what I want isn't what I really
want because something else looks potentially better misses the whole
point. It almost feels to me like you are basically saying I am not
allowed to have a traditional sort of appearance because you don't think
it looks as good, no matter if I do actually want or even prefer the one
over the other. 

As it happen I have actually implemented some code dealing with bevels
as gradients just as you describe, I think they are nice, but thats
beside the point of me wanting to be able to draw things in a more
traditional style as it were, from within the same framework. As is I
would have to maintain two separate drawing mechanisms accordingly to
achieve what I want.

Sure, I could always draw arcs/lines manually pixel by pixel, but I find
that completely repugnant. 

Cairo appears to be the wave of the future. I have no problems with that
so long as I can continue to do things as before, in addition to being
able to do them better.

-- 
Andrew Johnson <acjgenius at earthlink.net>