🚀 go-pugleaf

"David HAROUCHE" <metanil@hotmail.com> wrote in message 
news:487ea677$1@newsgroups.borland.com...
> What will be the most efficient ?
>
> DH
>

do a test and find out

cheers,
Paul 

ScanLine...

DH 

I found that drawing a line using ScanLine and a geometrical algorythm ( y= 
ax + b) goes faster than using LineTo...

>> think scanline will be that efficient drawing a line on a printer's 
>> canvas.
I don't know about the printer...What I plane to use about it is CopyRect 
from TBitmap to TPrinter....(eventually producing a WMF file)...

>> If you expect assistence, you need to learn how to ask better questions.
better ?

DH 

"David HAROUCHE" <metanil@hotmail.com> wrote in
> What will be the most efficient ?

Efficient at *what*?  They are two completely different things.  I dont 
think scanline will be that efficient drawing a line on a printer's canvas.

If you expect assistence, you need to learn how to ask better questions.

I just calculate each y from two given points using y=ax +b and light a 
pixel using scanline... So I keep the "control" until the end... !

DH 

David HAROUCHE wrote:

> I found that drawing a line using ScanLine and a geometrical algorythm (
> y= ax + b) goes faster than using LineTo...

In addition to other replies, please notice that there is many algorithms to
draw a line, depending on drawing speed and quality. There is also many
serious discussions and articles about this "simple" theme...

In this particular case, significant part of speed dependeds on chosen
algorithm as well, by side of the method LineTo actualy use to draw a pixel
on specific destionation (assuming thus is word about TBitmap).

David HAROUCHE wrote:

> I just calculate each y from two given points using y=ax +b and light a
> pixel using scanline... So I keep the "control" until the end... !

This is perhaps quality, but hardly the fastest way. Main difference between
mathematical and computer line is infinite number of dots in mathematical
definition of a line and finite number of squares (pixels) in comuter
graphics. That mean we need to make aproximation algorithm which will turn 
on the squares which ideal line cross. Thus we have a line composed of N
horizontal and M vertical lines depending on angle and the problem stays to
determinate how many of them will be necessary.

In case of using explicit formula to calculate each y, assume x
multiplifications and adding, which is hardly optimal. We will have many 
round(a*x) values equal (depending on angle). In case of optimiztion we
need to determinate how many (and how long) horiyontal and vertical line we
will draw, which assume N adding only. One of the first results on this
approximation is Bresenam's algorithm.

David HAROUCHE wrote:

> I just calculate each y from two given points using y=ax +b and light a
> pixel using scanline... So I keep the "control" until the end... !

This is perhaps quality, but hardly the fastest way. Main difference between
mathematical and computer line is infinite number of dots in mathematical
definition of a line and finite number of squares (pixels) in comuter
graphics. That mean we need to make aproximation algorithm which will turn 
on the squares which ideal line cross. Thus we have a line composed of N
horizontal and M vertical lines depending on angle and the problem stays to
determinate how many of them will be necessary.

In case of using explicit formula to calculate each y, assume x
multiplifications and adding, which is hardly optimal. We will have many 
round(a*x) values equal (depending on angle). In case of optimiztion we
need to determinate how many (and how long) horiyontal and vertical line we
will draw, which assume N adding only. One of the first results on this
approximation is Bresenham's algorithm.

Yes,

and you can't imagine how faster it runs when you correctly bufferize the 
drawings...

DH 

I found that with Delphi, when you can light up all pixels using ScanLine 
(regardless 3D/2D scales and ranges checks),
you can use geometrical approach for drawing, quicker (in terme of drawing 
speed) than using GDI/VCL functions...

The speed can be increased from dramatical to OpenGL's concurrency...

DH 

David HAROUCHE wrote:

> and you can't imagine how faster it runs when you correctly bufferize the
> drawings...

Well, I made quite large ammount of low level coding regarding computer
graphic (Image Processing task related) and Delphi in the past... Some of
the basics stuff can be found at Booland newsgroups arhive at
www.tamaracka.com (search for "Sasa scanline"). It may be interesting to
look.

Sasa Zeman wrote:

> One of the first results on this
> approximation is Bresenham's algorithm.

Windows has a build-in version of that, by the way: the LineDDA API
function.

-- 
Peter Below (TeamB)  
Don't be a vampire (http://slash7.com/pages/vampires), 
use the newsgroup archives :
http://www.tamaracka.com/search.htm
http://groups.google.com

>> Windows has a build-in version of that, by the way: the LineDDA API
>> function.
Yes, but I need to have control for every pixel I do light up !

DH 

David HAROUCHE wrote:
>>> Windows has a build-in version of that, by the way: the LineDDA API
>>> function.
> Yes, but I need to have control for every pixel I do light up !

You do have that control with the LineDDA, as it calls back to you for each 
pixel to draw. Unfortunately, this makes it rather slow, comapared to 
scanline drawing.

-- 
Anders Isaksson, Sweden
BlockCAD:  http://web.telia.com/~u16122508/proglego.htm
Gallery:   http://web.telia.com/~u16122508/gallery/index.htm

>> You do have that control with the LineDDA, as it calls back to you for 
>> each pixel to draw. Unfortunately, this makes it rather slow, comapared 
>> to scanline drawing.
...and quick drawings...

DH 

Look up the Bresenham line agorithm.

If you want quality lines, just lighting up single pixels as on/off is 
*bad*. You have to work with semi-transparency.

Nils

"David HAROUCHE" <metanil@hotmail.com> schreef in bericht 
news:48812c28@newsgroups.borland.com...
>I just calculate each y from two given points using y=ax +b and light a 
>pixel using scanline... So I keep the "control" until the end... !
>
> DH
> 

I use a vector approach of the drawings, and a RGBTriple access for 
lightning up any pixel...My first object for that one I wrote, named TLight.

Works like that :

with TLight.Create(mybitmap, x, y)
    do begin
                Transparency := 50;   // set its transparency (according to 
the "under/actual" pixel)
                Color := clBlue;        // set its color

               Commit;            // That applys the changes (with VCL, a 
ScanLine operation will be done on mybitmap)

              Free;
      end;

for drawing a line, I do use something like :

l:=TLine(A,B); // that creates an y=ax+b object from two given points...

with TLight.Create(MyBitmap)
    do begin
                i:= A.x

               while i <= B.x
                    do begin
                                 x := i:
                                y := l.a * x + l.b;
                                color := mycolor;

                              Commit;

                             i := i + 1; // here  I can play to draw dotted 
or not lines
                        end;

               free;
        end;

That goes nearly faster than Canvas.LineTo ! And its very usefull for 3D 
translation...

DH