Re: Drawing antialiased shapes with alpha transparency

[Samuel Abels <newsgroups debain org>]

On Tue, 2005-01-04 at 17:47 -0500, Paul Davis wrote:
> >I have used the Gnomemm-Canvas before (~max 1 year ago), but even in
> >simple test cases it had display error back then. Also, from what I have
> >read on a gnome mailing last month (unfortunately I was not able to find
> >the mail again) the gnome canvas is now basically unmaintained.
> 
> true. but there are several projects using it in various forms,
> including my own (http://ardour.org/). its a very, very powerful
> widget with or without official support. 
> 
> i would encourage you to reconsider the canvas.

Even if it were maintained the gnome canvas is not really an option,
since I require support for rotation of shapes and I require all widgets
to use rotation axis coordinates rather than "north-west-edge
coordinates". I also made some other design decisions that IMO make a
more intuitive API:

canvas.add(new pCanvasLeafPolygonSquare(100), 50, 50);

instead of

new Gnome::Canvas::Rect(canvas.root(), 0, 0, 100, 100);

This also makes it easy to use a factory/flyweights for some objects if
that should become necessary.

Either way, since the design is finished and and pretty much works
already it wouldn't make much sense to redecide anymore ;).

> >I have found Gdk::RGB mentioned all over the API docs, but I didn't find
> >it documented anywhere. I only found
> >http://www.gtkmm.org/docs/gtkmm-2.4/docs/reference/html/classGdk_1_1RgbCmap.html
> >in the Gdk namespace. Is this what you mean with the RGB buffer? How
> >would I draw that to a drawable?
> 
> 1) no, i meant a literal RGB buffer, with N bits per pixel, and N/3
>    bits per color value. 
> 
> 2) i don't use Drawables. they are slow for this kind of thing. you
>    want to render to some non-X-buffer, then just draw that into
>    some kind of Drawable in a single pass, with the z-order stacking
>    and AA already taken care of.

The canvas design is made in a way that, once cached, every pixel is
drawn in one single pass, so I can draw immediately to whatever surface
there is and no pixel is touched twice.

As you suggested, I will try and use libart to draw to RGB buffers for
the caching, then copy from there to either the drawable, or if that
turns out to be too slow, to another widget; I do not think that should
be necessary though, as it is fast enough now already.

> this is where the AA canvas comes in. for 2D drawing, libart_lgpl is
> very powerful, and pretty damn fast. it has full AA support for the
> polygons and other things it can draw. its already used by the
> existing canvas items.

This is great, I will use libart for that purpose.

> i merged a set of macros for RGB(A) drawing into my project, its
> GPL'ed by some other people, you're welcome to take a look if you
> want. it just has primitives for drawing lines, rects etc. very
> primitive but very fast.

If they support AA, that sounds like a good option in case libart might
still turn out not to work.

Thanks a lot for the information, this was very helpful.

-Samuel
-- 
 ------------------------------------------------------
|      Samuel Abels       |   http://www.debain.org    |
| spam ad debain dod org  | knipknap ad jabber dod org |
 ------------------------------------------------------