Re: Ellipses & Antialiasing
From: Tony Cook (firstname.lastname@example.org)
Date: Fri 18 Apr 2008 - 00:48:47 GMT
On Thu, Apr 17, 2008 at 04:41:13PM +0200, Bruno Czekay wrote:
> 2008/4/17, Tony Cook <email@example.com>:
> > On Wed, Apr 16, 2008 at 12:11:53PM +0200, Bruno Czekay wrote:
> > >
> > > 1. At the moment, Imager does not support drawing ellipses (or arcs of
> > > elliptical shape). Is this feature somewhere near on the TODO list?
> > AFAIK it
> > > depends on some new C function in the underlying library.
> > This is the first time I recall anyone asking for it.
> To be honest, I ask because some time ago I was involved into creating some
> image-for-PDF-generator and I've sticked to Imager (which still seems very
> good decision for me!). Now the customer wants to use some SVG implants,
> which in turn means having possibility to draw an ellipse (just in case)...
> A complete ellipse, with the axes of symmetry parallel to the X and Y
> > axes is pretty simple to support.
> > Complexities include:
> > a) when drawing a pie segment, are the angles specified the real
> > angles (since the scaling changes the angles if you just use sin() and
> > cos() directly) or the angle before scaling? I can see cases where
> > both are useful.
> This is right. However, as the basic function should drive ellipse (or
> ellipses arc), calculating right angles should bother the function that
> creates piecharts, not ellipses. So I suppose "an angle" should mean "an
> angle of the ellipse", not "an angle of the skewed circle".
> b) can you control the angles of the axes of symmetry? (the axes would
> > remain at right angles to each other) Does this change the effect of
> > the d1 and d2 parameters?
> I assume the right angle (pi/2) between axes. Fancies can be obtained using
> Matrix2d->shear (correct me if I'm wrong).
Well, typically Imager's drawing primitives don't refer to a
But I didn't mean changing the angle between the major and minor axes,
but the angle between the major axis and the x axis - so more a
> I've added this to the TODO list.
> I've been thinking about using Bresenhams algorithm - for lines, arcs,
> circles and ellipses. However, I wouldn't like to mess with your plans
> regarding the code. If I could be useful, I'll ask my boss if I could spend
> some "official time" with it.
The non-AA line drawing code uses Bresenham's algorithm, the AA code
> > 2. In the POD for Imager::Draw one can read "box, arc, do not support
> > > antialiasing yet", however there are calls to functions like i_circle_aa
> > or
> > > i_arc_aa. I tried an arc with aa => 1 and it works fine (hovewer it is
> > > filled, as the POD says).
> > You're right. Anti-aliased arc() fills were added in 0.46. I've
> > corrected the BUGS section for the next release.
> I suppose it would be also nice to have a possibility to draw an empty
> (transparent) circle/arc/line/box/polygon of a given thickness.
I'm planning on adding thick lines for the next release, though I'm
bouncing between work, some imager.perl.org website updates and other
modules at the moment.