view release on metacpan or  search on metacpan

lib/Image/Base.pm  view on Meta::CPAN

default.

=back

=head1 ALGORITHMS

=head2 Lines

Sloping lines are drawn by a basic Bressenham line drawing algorithm with
integer-only calculations.  It ends up drawing the same set of pixels no
matter which way around the two endpoints are passed.

Would there be merit in rounding odd numbers of pixels according to which
way around line ends are given?  Eg. a line 0,0 to 4,1 might do 2 pixels on
y=0 and 3 on y=1, but 4,1 to 0,0 the other way around.  Or better to have
consistency either way around?  For reference, in the X11 drawing model the
order of the ends doesn't matter for "wide" lines, but for
implementation-dependent "thin" lines it's only encouraged, not required.

=head2 Ellipses

lib/Image/Base.pm  view on Meta::CPAN

each side.  Just one line is calculated and is then replicated to the four
sides, which ensures the result is symmetric.  Rounding in the line (when
width not a multiple or height, or vice versa) is biased towards making the
pointier vertices narrower.  That tends to look better, especially when the
diamond is small.

=head2 Image Libraries

The subclasses like GD or PNGwriter which are front-ends to other drawing
libraries don't necessarily use these base algorithms, but can be expected
to something sensible within the given line endpoints or ellipse bounding
box.  (Among the image libraries it's surprising how variable the quality of
the ellipse drawing is.)

=head1 SEE ALSO

L<Image::Xpm>,
L<Image::Xbm>,
L<Image::Pbm>,
L<Image::Base::GD>,
L<Image::Base::Imager>,