Delphi grahpic, slow?
Wayne Sherman
6.0!
> His algorythm is approx. 200 times faster than mine :-( . He wont tell me
> how he's done that! Like, I'm using Borland tools, and this is the only
> reason for slow work(That are his words). I just don't like to loose, so
> help!!!
The speed difference you are seeing in not due to the tools.
I would venture to say that you can produce code in Delphi that runs faster
than your friends current implementation. Accessing the bitmap data
directly using the Scanline property (or with pointers) instead of using the
Pixels property will give you your biggest improvement.
For Delphi optimizing techniques, try this site:
http://www.optimalcode.com
If you still need more speed, try explaining your implementation in more
detail, perhaps posting some code. There are many talented folks that roam
these groups that can offer further optimization suggestions.
Regards,
Wayne
Dalibor Krleza(MDM Team)
I have a problem which was bothering me for a while, now finally I
can ask someone about it....
I was doing some modules for pattern recognition. I had a picture
320*240, 256 gray levels. The main task to do on this picture was
a simple segmentation. I was using TImage component, and following
methods: Canvas->Pixels[x,y].
I couldn't believe, that it takes 250ms to scan this picture!?!? It was
too slow for me. Actually, I tried to use GetPixel API instead, there was
no big difference. I allso tried to use TPaintBox. Without any difference.
The AVI I have used, was/should be uploaded directly into memory, and
splitted manually. OK, this is the fastest method to do segmentation on AVI.
But (there is allways some "but"). It seems that drawing on TImage or
TPaintBox is even slower than reading. How to make this going fast?!
For comparison, my friend had made similar algorythm, but in Visual C++ 6.0!
His algorythm is approx. 200 times faster than mine :-( . He wont tell me
how he's done that! Like, I'm using Borland tools, and this is the only
reason for slow work(That are his words). I just don't like to loose, so
help!!!
Dalibor!
Jack Sudarev
news:3a0a4627_1@dnews...
..
> I was doing some modules for pattern recognition. I had a picture
> 320*240, 256 gray levels. The main task to do on this picture was
> a simple segmentation. I was using TImage component, and following
> methods: Canvas->Pixels[x,y].
Dalibor,
use Scanline property instead. It`s much more faster. Also you might want
to check Earl Glyn great site:
http://www.efg2.com/lab/Default.htm
Regards,
Jack Sudarev.
Jack Sudarev
> 320*240, 256 gray levels. The main task to do on this picture was
> a simple segmentation. I was using TImage component, and following
> methods: Canvas->Pixels[x,y].
Dalibor,
use Scanline property instead. It`s much more faster. Also you might want
to check Earl Glynn great site:
Francis Burton
Yes it is a wonderful site!
However, I have a question: Why cannot a version of .Pixels[x,y],
which is fully compatible with the existing one but which uses
Scanline, be substituted for the current slow one? That
would speed up "naive" code using the Pixels property (though
certain access patterns would be faster than others I guess).
Are there any reasons why this is not possible or might be
undesirable?
Francis
Wayne Niddery (TeamB)
>
>I was doing some modules for pattern recognition. I had a picture
>320*240, 256 gray levels. The main task to do on this picture was
>a simple segmentation. I was using TImage component, and following
>methods: Canvas->Pixels[x,y].
>
>I couldn't believe, that it takes 250ms to scan this picture!?!? It was
>too slow for me. Actually, I tried to use GetPixel API instead, there was
>no big difference. I allso tried to use TPaintBox. Without any difference.
You should also try posting this in borland.public.delphi.graphics.
--
Wayne Niddery (WinWright Inc.)
RADBooks - http://members.home.net/wniddery/
I love deadlines. I like the whooshing sound they make as they pass by -
Douglas Adams
Stuart Borden
> which is fully compatible with the existing one but which uses
> Scanline, be substituted for the current slow one? That
> would speed up "naive" code using the Pixels property (though
> certain access patterns would be faster than others I guess).
> Are there any reasons why this is not possible or might be
> undesirable?
You need to remember that a property is not a magic acess to any sort of data
when used as arrays. It is a FUNCTION call. And these, unfortunately, are
EXTREMELY slow in the world of real time. There is NO way to implement a fast
array property. At the least, you have to pass two paramters to access each
pixel. The execution time cost for this is horrendous. And the call itself is
even worse (MUCH worse). And to do this for each pixel...
(rant)
Well, now you begin to understand WHY we need GHz+ speed computers. All these
great OOP techniques and philosophies were NEVER intended to make code RUN
more efficiently. It was developed to make the development, management and
maintenance of ever-more-complicated and large applications more efficient
(and even possible). Anything that can be done with OOP can (and usually has
been) done without it and will run significantly faster (sometimes 10-20x).
But in software the adage is speed and code size/complexity are inversely
proportional. Windows is already a monster. Try to implement it in straight
assembler will yield probably 5x+ performance. But it would take
man-centuries of coding and would probably need 4 CDs.
(/rant)
You need to mix. When speed is essential, call a function that performs the
entire "operation" you wish to do, and inside this function INLINE, INLINE,
INLINE as much as you can and avoid all function calls you can.
Best of luck,
Stuart Borden.
Francis Burton
Stuart Borden <is...@chollian.net> wrote:
>You need to remember that a property is not a magic acess to any sort of data
>when used as arrays. It is a FUNCTION call. And these, unfortunately, are
>EXTREMELY slow in the world of real time. There is NO way to implement a fast
>array property. At the least, you have to pass two paramters to access each
>pixel. The execution time cost for this is horrendous. And the call itself is
>even worse (MUCH worse). And to do this for each pixel...
Stuart,
Thanks for your analysis - very interesting. I wonder
if there might be any way round the need to make slow
function calls in accessing array properties through
some clever optimisation? Maybe it is just too hard
a task for even today's sophisticated compilers.
Francis
Stuart Borden
even private can be used it it is used within the scope of the module. Also, many
functions give methods/properties to access to large chunks at a time. You can use
these to get local copies of the data for processing. Access to a pointer to where
the actual data resides can also be very helpful if you're careful. As for
optimizing the compiler, the compilers don't always have control of these things as
the OS memory managers can alocate memory in non-optimal chunks. (i.e., if the
routine you're calling does not reside in the on-board RAM and has to be swapped in
from disk...).
Stuart Borden.
Francis Burton wrote:
> In article <3A0F39E9...@chollian.net>,
> Stuart Borden <is...@chollian.net> wrote:
> >You need to remember that a property is not a magic acess to any sort of data
> >when used as arrays. It is a FUNCTION call. And these, unfortunately, are
> >EXTREMELY slow in the world of real time. There is NO way to implement a fast
> >array property. At the least, you have to pass two paramters to access each
> >pixel. The execution time cost for this is horrendous. And the call itself is
> >even worse (MUCH worse). And to do this for each pixel...
Rudy Velthuis
Stuart and Francis, you both seem to be posting to a Usenet copy of the
original Borland newsgroups. People using the Borland servers won't be
able to see your message. Please point your newsreader to a Borland
server, and read the FAQ mentioned below.
I saw your messages in my local ISP's Usenet copy of the original Borland
groups.
--
Rudy Velthuis (TeamB) http://delphi-jedi.org
Use Borland servers; Posts via ISPs are not seen by TeamB
http://www.borland.com/newsgroups/genl_faqs.html