[cairo] Antialiasing and round, bevelled widgets (was: Cairo
developers conference call...)
otaylor at redhat.com
Tue Oct 19 10:26:26 PDT 2004
On Tue, 2004-10-19 at 12:11 -0400, Carl Worth wrote:
> > I do understand that you are trying to keep cairo's APIs clean and that it's
> > not a pixel oriented library, but somehow I have to find a way to still
> > achieve my goals on top of it since it is the chosen way to implement GDI+
> > for us. And since I'm not smart enough to just 'hack' cairo to do what we
> > need, I have to keep asking & nagging you. I really appreciate you even
> > still talking about the subject, even though you probably are getting tired
> > of it at this point.
> No, I'm not getting tired of it. I really do want to understand what
> users of cairo want--particularly when cairo isn't meeting those
> needs. It may yet be that you convince me to add a non-antialiasing mode
> to cairo, (and it may turn out to not be a huge effort). But I don't
> want to do that without a very good understanding of why it's needed. So
> I'll ask you to be patient with me as I keep probing deeper.
A big question to me is whether anything in this area is going to meet
the original requirements that Ravindra brought up.
It's not clear to me that any sort of non-antialiased" or "edge-
snapped" mode that doesn't match the pixelization guarantees (*) of the
Windows GDI will be useful for programs that use System.Windows.Forms or
And I don't think trying to address non-antialiased drawing without
addresssing the rasterops question is useful for this type of
By the far the most common reason people ask for non-antialiased drawing
of text in GTK+ (not currently possible) is that they want to use
XOR to undraw something they drew earlier.
I'm not suggesting that Cairo should have a classic GDI/XLib mode, but
rather that we need to think about what, if anything is needed to
enable people who need to emulate this type of classic GDI/XLib drawing.
Do we need afast-pathed special case for span-lists or rectangle-lists?
A way of integrating direct frame buffer access?
For GTK+, my plan is to not try and re-base stuff like gdk_draw_line()
on top of Cairo, but rather to simply add whatever synchronization is
necessary so that mixing gdk_draw_line() and Cairo works reasonably
(*) Yes, the Windows GDI pixelization "guarantees" are loose, but they
(**) The obvious downside of this is that new ports of GDK have to port
both Cairo and the old GDK drawing stuff.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20041019/e99de1d9/attachment.pgp
More information about the cairo