[cairo] Antialiasing and round, bevelled widgets (was: Cairo
developers conference call...)
acjgenius at earthlink.net
Mon Oct 18 16:26:34 PDT 2004
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
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>
More information about the cairo