Discussion:
fast drawing in delphi
(too old to reply)
Maldona8
2005-12-17 23:05:48 UTC
Permalink
Looking for algorithms, source codes for fast drawing routines in Delphi
I have a hexagonal grid of 100x100 hexagons, each hexagon having its own
color.
I need to draw this map in a very very fast way, the faster possible.
What Delphi technology would you recommend to do this job?
Thanks in advance for your help!
Andreas Koch
2005-12-18 09:27:37 UTC
Permalink
Post by Maldona8
Looking for algorithms, source codes for fast drawing routines in Delphi
I have a hexagonal grid of 100x100 hexagons, each hexagon having its own
color.
I need to draw this map in a very very fast way, the faster possible.
What Delphi technology would you recommend to do this job?
Either bitmap.scanline, and set the pixels one per one as you need them.

Or use canvas.copyrect with transparent copymode to copy pre-rendered
hexagons from a second canvas to the target (won't be of much use
if you have 100x100 different colors)
Maldona8
2005-12-18 10:21:58 UTC
Permalink
Hello Andreas!
Post by Andreas Koch
Either bitmap.scanline, and set the pixels one per one as you need them.
Andreas,
this method looks very interesting. Now the questions is: how to implement
drawing in a bitmap canvas using scanline????

I was searching for real coded examples in internet (google, altavista,
yahoo, lycos, etc) but couldnt find any examples of how to use scanline to
draw something simple like a square, a circle or a triangle, and then how to
play the bitmap canvas into a screen bitmap canvas...

it does make sense to use scanline but it is not finally the pixel by pixel
scanline method as slow as the traditional pixels[i,j] method?

Can you show an example (even pseudo-code will help) on how to use scanline
method to draw a rectangle in the screen?

Thanks for your help!
Post by Andreas Koch
Post by Maldona8
Looking for algorithms, source codes for fast drawing routines in Delphi
I have a hexagonal grid of 100x100 hexagons, each hexagon having its own
color.
I need to draw this map in a very very fast way, the faster possible.
What Delphi technology would you recommend to do this job?
Either bitmap.scanline, and set the pixels one per one as you need them.
Or use canvas.copyrect with transparent copymode to copy pre-rendered
hexagons from a second canvas to the target (won't be of much use
if you have 100x100 different colors)
Andreas Koch
2005-12-18 10:39:00 UTC
Permalink
Post by Maldona8
it does make sense to use scanline but it is not finally the pixel by pixel
scanline method as slow as the traditional pixels[i,j] method?
No. It is MUCH faster, as pixels does things like color space
conversions and repainting
(we are talking about native win32 applications. No idea if this applies
to .net).
Post by Maldona8
Can you show an example (even pseudo-code will help) on how to use scanline
method to draw a rectangle in the screen?
Make a new app, drap a TTimer and an TImage, then use following code.
Gives me 60 fps with an 800x600 TImage on my system (i think windows GDI
won't draw more than 60 fps in any case)

unit _scanlinetest;

interface

uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls,
Forms,
Dialogs, ExtCtrls;

type
TForm1 = class(TForm)
Image1: TImage;
Timer1: TTimer;
procedure FormCreate(Sender: TObject);
procedure FormDestroy(Sender: TObject);
procedure Timer1Timer(Sender: TObject);
private
{ Private-Deklarationen }
fps:integer;
public
{ Public-Deklarationen }
procedure MyIdleHandler(Sender: TObject; var Done: Boolean);
end;

var
Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.MyIdleHandler(Sender: TObject; var Done: Boolean);

var
p:pbytearray;
x,y,r,at:integer;

begin
for y:=0 to Image1.picture.bitmap.height-1 do
begin
p:=Image1.picture.bitmap.scanline[y];
at:=0;
for x:=0 to Image1.picture.bitmap.width-1 do
begin
r:=random(256); // make this pixel a random gray
p[at]:=r;inc(at); // (TV noise effect)
p[at]:=r;inc(at);
p[at]:=r;inc(at);
end;
end;
Image1.repaint;
Done:=False;
inc(fps);
end;


procedure TForm1.FormCreate(Sender: TObject);
begin
doublebuffered:=true;
application.OnIdle:=myIdleHandler;
Image1.picture.bitmap.width:=image1.width;
image1.picture.bitmap.height:=image1.height;
image1.picture.bitmap.pixelformat:=pf24bit;
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
application.OnIdle:=nil;
end;

procedure TForm1.Timer1Timer(Sender: TObject);
begin
caption:=inttostr(fps);
fps:=0;
end;

end.
Maldona8
2005-12-18 14:31:57 UTC
Permalink
Andreas,
yeah, the code is great and very easy to understand, thanks!
the TV snow simulation looks very nice,
but it doesn't show how to draw a simple rectangle using scanline...
drawing a simple square or triangle, this is what I would like to know how
to do with scanline
Ronald
Post by Maldona8
it does make sense to use scanline but it is not finally the pixel by
pixel scanline method as slow as the traditional pixels[i,j] method?
No. It is MUCH faster, as pixels does things like color space conversions
and repainting
(we are talking about native win32 applications. No idea if this applies
to .net).
Post by Maldona8
Can you show an example (even pseudo-code will help) on how to use
scanline method to draw a rectangle in the screen?
Make a new app, drap a TTimer and an TImage, then use following code.
Gives me 60 fps with an 800x600 TImage on my system (i think windows GDI
won't draw more than 60 fps in any case)
unit _scanlinetest;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls,
Forms,
Dialogs, ExtCtrls;
type
TForm1 = class(TForm)
Image1: TImage;
Timer1: TTimer;
procedure FormCreate(Sender: TObject);
procedure FormDestroy(Sender: TObject);
procedure Timer1Timer(Sender: TObject);
private
{ Private-Deklarationen }
fps:integer;
public
{ Public-Deklarationen }
procedure MyIdleHandler(Sender: TObject; var Done: Boolean);
end;
var
Form1: TForm1;
implementation
{$R *.dfm}
procedure TForm1.MyIdleHandler(Sender: TObject; var Done: Boolean);
var
p:pbytearray;
x,y,r,at:integer;
begin
for y:=0 to Image1.picture.bitmap.height-1 do
begin
p:=Image1.picture.bitmap.scanline[y];
at:=0;
for x:=0 to Image1.picture.bitmap.width-1 do
begin
r:=random(256); // make this pixel a random gray
p[at]:=r;inc(at); // (TV noise effect)
p[at]:=r;inc(at);
p[at]:=r;inc(at);
end;
end;
Image1.repaint;
Done:=False;
inc(fps);
end;
procedure TForm1.FormCreate(Sender: TObject);
begin
doublebuffered:=true;
application.OnIdle:=myIdleHandler;
Image1.picture.bitmap.width:=image1.width;
image1.picture.bitmap.height:=image1.height;
image1.picture.bitmap.pixelformat:=pf24bit;
end;
procedure TForm1.FormDestroy(Sender: TObject);
begin
application.OnIdle:=nil;
end;
procedure TForm1.Timer1Timer(Sender: TObject);
begin
caption:=inttostr(fps);
fps:=0;
end;
end.
Andreas Koch
2005-12-18 15:32:10 UTC
Permalink
Post by Maldona8
Andreas,
yeah, the code is great and very easy to understand, thanks!
the TV snow simulation looks very nice,
but it doesn't show how to draw a simple rectangle using scanline...
drawing a simple square or triangle, this is what I would like to know how
to do with scanline
By drawing all of its pixels, manually.
The example shows you how to draw a pixel, and all objects
consist of pixels.

Draw all pixels of the screen, one by one, and if its
between the left and the right side of the rectangle, and
between the top and the bottom side of the rectangle, draw it
in the color of the rectangle.
That assumes you have all hexagons or squares or triangles in
a sort of array, and don't want to draw a certain one out of order.
That will be the fastest method.
Maldona8
2005-12-18 15:45:49 UTC
Permalink
Andreas,
about your answer...
does it mean that if I need to draw rectangles or circles
I have to write the whole bunch of drawing functions
like Circle(x1,y1,x2,y2) or rectangle(x1,y1,x2,y2) etc?

Ronald
Post by Andreas Koch
Post by Maldona8
Andreas,
yeah, the code is great and very easy to understand, thanks!
the TV snow simulation looks very nice,
but it doesn't show how to draw a simple rectangle using scanline...
drawing a simple square or triangle, this is what I would like to know
how to do with scanline
By drawing all of its pixels, manually.
The example shows you how to draw a pixel, and all objects
consist of pixels.
Draw all pixels of the screen, one by one, and if its
between the left and the right side of the rectangle, and
between the top and the bottom side of the rectangle, draw it
in the color of the rectangle.
That assumes you have all hexagons or squares or triangles in
a sort of array, and don't want to draw a certain one out of order.
That will be the fastest method.
Paul Dunn
2005-12-18 16:42:45 UTC
Permalink
Post by Maldona8
Andreas,
about your answer...
does it mean that if I need to draw rectangles or circles
I have to write the whole bunch of drawing functions
like Circle(x1,y1,x2,y2) or rectangle(x1,y1,x2,y2) etc?
Yes, you will.

Google for Bressenham, both for lines and circles. Both can be extended to
produce triangles and ellipses, respectively.

A solid polygon is simple - take each vertex and sort the vertices top to
bottom. Calculate slope values and draw "spans" - between sides, left to
right. Using Fastlib, I can draw a few thousand polygons in one frame with
ease, but I tend to avoid using pascal to do it - it's far faster if you
roll your own in assembly rather than let Delphi's rather poor compiler do
the work, unless you're prepared to study the output code in a disassembler
to look for bottlenecks.

That's why I like fastlib, as it gives you low level access to the surface,
and high level through windows API. I've not tried Graphics32 for a long
time now, as Fastlib was a lot faster the last time I used it.

I'll mail you my Fastlib archive later on, and I'll supply a couple of demos
too.

D.
Maldona8
2005-12-20 13:46:28 UTC
Permalink
Dear Paul,
thank you! that's great.
I will try now the Google search for drawing routines.
I will be awaiting for your fastlib.
Ronald
Post by Paul Dunn
Post by Maldona8
Andreas,
about your answer...
does it mean that if I need to draw rectangles or circles
I have to write the whole bunch of drawing functions
like Circle(x1,y1,x2,y2) or rectangle(x1,y1,x2,y2) etc?
Yes, you will.
Google for Bressenham, both for lines and circles. Both can be extended to
produce triangles and ellipses, respectively.
A solid polygon is simple - take each vertex and sort the vertices top to
bottom. Calculate slope values and draw "spans" - between sides, left to
right. Using Fastlib, I can draw a few thousand polygons in one frame with
ease, but I tend to avoid using pascal to do it - it's far faster if you
roll your own in assembly rather than let Delphi's rather poor compiler do
the work, unless you're prepared to study the output code in a
disassembler to look for bottlenecks.
That's why I like fastlib, as it gives you low level access to the
surface, and high level through windows API. I've not tried Graphics32 for
a long time now, as Fastlib was a lot faster the last time I used it.
I'll mail you my Fastlib archive later on, and I'll supply a couple of
demos too.
D.
Andreas Koch
2005-12-18 18:30:41 UTC
Permalink
Post by Maldona8
does it mean that if I need to draw rectangles or circles
I have to write the whole bunch of drawing functions
like Circle(x1,y1,x2,y2) or rectangle(x1,y1,x2,y2) etc?
Yes, it means you can't use the system drawing functions.

I also suppose that you are trying some game map, e.g.
you want to draw your 10.000 hexagons all at once, at
fixed places.
In that case, you don't need to write a hexagon(x,y)-drawing
routine (you could if you wanted) but do it the other way
round.

Lets view a little map of only 3 hexagons, A, B and C

..AA......CC...
.AAAA....CCCC..
AAAAAABBCCCCCC.
.AAAABBBBCCCC..
..AABBBBBBCC...
.....BBBB......
......BB.......

You know, hexagon A should be red, B blue and C green.
So you paint line by line

y=0
x=0 background
x=1 background
x=2 oh, this is hex a, so red
x=3 still red
x=4 background
....

y=
x=0 background
x=1 oh, this is hex a, so red
x=2 red
x=3 red
x=4 red
x=5 background
...
etc

If an pixel at x,y is inside a hexagon can be (more or
less) simply calculated if you know the hexagons position
and size.
Maldona8
2005-12-20 13:42:15 UTC
Permalink
I see. I will try your idea...
It seems to be simply, tough...
The hexagons I use for making a neural network feature map (invented by
Teuvo Kohonen, in the early 70's)
In my work (as student), we have an incredible huge amount of data to
process. Each datum has 10 associated values.
Those values correspond to many 10-dimensional time-series. So, I put the
whole bunch of timeseries into a Kohonen map and see the
result in a Umatrix map. I developed a fast algorithm that identifies data
clusters in the Umatrix and then for visualization we need to redraw the
Umatrix and the 10 components into a 100x100 hexagons map.
Post by Andreas Koch
Post by Maldona8
does it mean that if I need to draw rectangles or circles
I have to write the whole bunch of drawing functions
like Circle(x1,y1,x2,y2) or rectangle(x1,y1,x2,y2) etc?
Yes, it means you can't use the system drawing functions.
I also suppose that you are trying some game map, e.g.
you want to draw your 10.000 hexagons all at once, at
fixed places.
In that case, you don't need to write a hexagon(x,y)-drawing
routine (you could if you wanted) but do it the other way
round.
Lets view a little map of only 3 hexagons, A, B and C
..AA......CC...
.AAAA....CCCC..
AAAAAABBCCCCCC.
.AAAABBBBCCCC..
..AABBBBBBCC...
.....BBBB......
......BB.......
You know, hexagon A should be red, B blue and C green.
So you paint line by line
y=0
x=0 background
x=1 background
x=2 oh, this is hex a, so red
x=3 still red
x=4 background
....
y=
x=0 background
x=1 oh, this is hex a, so red
x=2 red
x=3 red
x=4 red
x=5 background
...
etc
If an pixel at x,y is inside a hexagon can be (more or
less) simply calculated if you know the hexagons position
and size.
Paul Dunn
2005-12-18 10:49:51 UTC
Permalink
Post by Maldona8
Looking for algorithms, source codes for fast drawing routines in
Delphi I have a hexagonal grid of 100x100 hexagons, each hexagon
having its own color.
I need to draw this map in a very very fast way, the faster possible.
What Delphi technology would you recommend to do this job?
Thanks in advance for your help!
Have a search for Gordy's FastLib. It exposes the DIB as a pointer to a flat
array of bytes, which you can access through a pointer. It's a lot faster
than the bitmap.scanlines method, especially when mixed with a little
assembly language. You can also use the win32 API graphics commands on it,
or pass it as a surface to DirectX for rendering to that.

I use it for very fast graphics in an emulator.

Unfortunately, Gordy no longer maintains FastLIB, and the person who took it
over doesn't seem to offer it for download any longer. If you're stuck, I
can zip it up and send it to you.

D.
Maldona8
2005-12-18 13:36:44 UTC
Permalink
Dear Paul,
yes, please,send the zip. I would love to try this routines!
thanks!
Ronald
Post by Paul Dunn
Post by Maldona8
Looking for algorithms, source codes for fast drawing routines in
Delphi I have a hexagonal grid of 100x100 hexagons, each hexagon
having its own color.
I need to draw this map in a very very fast way, the faster possible.
What Delphi technology would you recommend to do this job?
Thanks in advance for your help!
Have a search for Gordy's FastLib. It exposes the DIB as a pointer to a
flat array of bytes, which you can access through a pointer. It's a lot
faster than the bitmap.scanlines method, especially when mixed with a
little assembly language. You can also use the win32 API graphics commands
on it, or pass it as a surface to DirectX for rendering to that.
I use it for very fast graphics in an emulator.
Unfortunately, Gordy no longer maintains FastLIB, and the person who took
it over doesn't seem to offer it for download any longer. If you're stuck,
I can zip it up and send it to you.
D.
Maarten Wiltink
2005-12-18 12:02:38 UTC
Permalink
Post by Maldona8
Looking for algorithms, source codes for fast drawing routines in
Delphi. I have a hexagonal grid of 100x100 hexagons, each hexagon
having its own color.
I need to draw this map in a very very fast way, the faster possible.
What Delphi technology would you recommend to do this job?
Easy WinAPI integration. Call Polygon() and let hardware acceleration
sort out the rest.

Groetjes,
Maarten Wiltink
Maldona8
2005-12-18 14:00:59 UTC
Permalink
yeah, that seems also an interesting way to do the job. I will try it right
now...
WInAPI, do you mean something like this? :

Procedure TForm1.Button1Click(Sender: TObject);
Var
pntArray : array[0..9] of TPOINT;
PntCounts : array[0..1] of integer;
Begin
PntArray[0] := Point(0, 0);
PntArray[1] := Point(0, 100);
PntArray[2] := Point(100, 100);
PntArray[3] := Point(100, 0);
PntArray[4] := Point(0, 0);
PntCounts[0] := 5;
PntArray[5] := Point(25, 25);
PntArray[6] := Point(25, 75);
PntArray[7] := Point(75, 75);
PntArray[8] := Point(75, 25);
PntArray[9] := Point(25, 25);
PntCounts[1] := 5;
PolyPolygon(Form1.Canvas.Handle, PntArray, PntCounts, 2);
end;

Thanks Marteen!
Groetjes,
Ronald
Post by Maarten Wiltink
Post by Maldona8
Looking for algorithms, source codes for fast drawing routines in
Delphi. I have a hexagonal grid of 100x100 hexagons, each hexagon
having its own color.
I need to draw this map in a very very fast way, the faster possible.
What Delphi technology would you recommend to do this job?
Easy WinAPI integration. Call Polygon() and let hardware acceleration
sort out the rest.
Groetjes,
Maarten Wiltink
Maarten Wiltink
2005-12-19 09:52:54 UTC
Permalink
"Maldona8" <***@etu.unige.ch> wrote in message news:43a56b92$***@nntp.unige.ch...

[...]
----+----*----+----*----+----*----+----*----+----*----+----*----+----*----+-
---*
Post by Maldona8
Procedure TForm1.Button1Click(Sender: TObject);
Var
pntArray : array[0..9] of TPOINT;
PntCounts : array[0..1] of integer;
Begin
PntArray[0] := Point(0, 0);
PntArray[1] := Point(0, 100);
PntArray[2] := Point(100, 100);
PntArray[3] := Point(100, 0);
PntArray[4] := Point(0, 0);
PntCounts[0] := 5;
PntArray[5] := Point(25, 25);
PntArray[6] := Point(25, 75);
PntArray[7] := Point(75, 75);
PntArray[8] := Point(75, 25);
PntArray[9] := Point(25, 25);
PntCounts[1] := 5;
PolyPolygon(Form1.Canvas.Handle, PntArray, PntCounts, 2);
end;
Yes. BTW, I think MSDN says you don't need to include the last, closing,
line.
Post by Maldona8
Thanks Marteen!
(Cough)

Groetjes,
Maarten Wiltink
Maldona8
2005-12-20 13:51:54 UTC
Permalink
Marteen,
I try it (with Delphi 5) what the MSDN says about not including the last
line.
It is not true. If I dont include the last line, the program simply draws
any crazy lines out of the double enclosed squares.
Did you tried it?
Post by Maarten Wiltink
[...]
----+----*----+----*----+----*----+----*----+----*----+----*----+----*----+-
---*
Post by Maldona8
Procedure TForm1.Button1Click(Sender: TObject);
Var
pntArray : array[0..9] of TPOINT;
PntCounts : array[0..1] of integer;
Begin
PntArray[0] := Point(0, 0);
PntArray[1] := Point(0, 100);
PntArray[2] := Point(100, 100);
PntArray[3] := Point(100, 0);
PntArray[4] := Point(0, 0);
PntCounts[0] := 5;
PntArray[5] := Point(25, 25);
PntArray[6] := Point(25, 75);
PntArray[7] := Point(75, 75);
PntArray[8] := Point(75, 25);
PntArray[9] := Point(25, 25);
PntCounts[1] := 5;
PolyPolygon(Form1.Canvas.Handle, PntArray, PntCounts, 2);
end;
Yes. BTW, I think MSDN says you don't need to include the last, closing,
line.
Post by Maldona8
Thanks Marteen!
(Cough)
Groetjes,
Maarten Wiltink
Maarten Wiltink
2005-12-20 14:53:08 UTC
Permalink
Post by Maldona8
Marteen,
(Psst. That's not my name.)
Post by Maldona8
I try it (with Delphi 5) what the MSDN says about not including the
last line.
It is not true. If I dont include the last line, the program simply
draws any crazy lines out of the double enclosed squares.
Did you tried it?
No. Obviously MSDN lied. By all means, do what works. (-:

Groetjes,
Maarten Wiltink
Francis Burton
2005-12-18 14:53:50 UTC
Permalink
Post by Maldona8
Looking for algorithms, source codes for fast drawing routines in Delphi
I have a hexagonal grid of 100x100 hexagons, each hexagon having its own
color.
I need to draw this map in a very very fast way, the faster possible.
What Delphi technology would you recommend to do this job?
Thanks in advance for your help!
In addition to what has already been suggested, you might like
to look at Alex Denisov's Graphics32 library. It works, is stable,
has reasonable documentation (but study the example programs too)
and is blisteringly fast (at least it is on my computer). If you
ever need stuff like layers and transparency, this library does it.

http://www.g32.org/

Francis
Maldona8
2005-12-18 15:28:55 UTC
Permalink
Great ! Thanks!
SourceForge net. great! Looks very useful! thanks!
Ronald
Post by Francis Burton
Post by Maldona8
Looking for algorithms, source codes for fast drawing routines in Delphi
I have a hexagonal grid of 100x100 hexagons, each hexagon having its own
color.
I need to draw this map in a very very fast way, the faster possible.
What Delphi technology would you recommend to do this job?
Thanks in advance for your help!
In addition to what has already been suggested, you might like
to look at Alex Denisov's Graphics32 library. It works, is stable,
has reasonable documentation (but study the example programs too)
and is blisteringly fast (at least it is on my computer). If you
ever need stuff like layers and transparency, this library does it.
http://www.g32.org/
Francis
Hans-Peter Diettrich
2005-12-18 17:51:54 UTC
Permalink
Post by Maldona8
Looking for algorithms, source codes for fast drawing routines in Delphi
I have a hexagonal grid of 100x100 hexagons, each hexagon having its own
color.
AFAIR you can copy a monochrome bitmap into an colored DC, resulting in
a copy with the color of your choice.
Post by Maldona8
I need to draw this map in a very very fast way, the faster possible.
What Delphi technology would you recommend to do this job?
IMO fast drawing nowadays is a job of DirectX and the accelerated
graphics cards. Drawing pixels might be slower than copying whole
bitmaps. At least you should test all high-level graphics options,
before deciding to tweak pixels.

DoDi
Maldona8
2005-12-20 14:05:18 UTC
Permalink
DoDI, wait a moment,

DoDi, did you mean, to create a monochrome bitmap
directly in memory and then forcing copy bitmap regions to screen?
I have to try it to see how it works...
AFAIR you can copy a monochrome bitmap into an colored DC, resulting in a
copy with the color of your choice.
I have 100x100 hexagons in the image. Each hexagon has a individual color,
indepently of any other hexagon colors, neighbors, etc.

Is DirectX the fastest technology for screen drawing?
bitmaps. At least you should test all high-level graphics options, before
deciding to tweak pixels.
SO, does it means
1) to use DIB or WMF or EMF to draw something
(100x100 hexagons for example) in a bitmap in RAM memory
2) play the Bitmap memory into Screen memory through VideoCard ASM
instructions or DirectX

Any web site you recommend for learning to use how to draw, print, save and
load images with DirectX??
Thanks!
Post by Maldona8
Looking for algorithms, source codes for fast drawing routines in Delphi
I have a hexagonal grid of 100x100 hexagons, each hexagon having its own
color.
AFAIR you can copy a monochrome bitmap into an colored DC, resulting in a
copy with the color of your choice.
Post by Maldona8
I need to draw this map in a very very fast way, the faster possible.
What Delphi technology would you recommend to do this job?
IMO fast drawing nowadays is a job of DirectX and the accelerated graphics
cards. Drawing pixels might be slower than copying whole bitmaps. At least
you should test all high-level graphics options, before deciding to tweak
pixels.
DoDi
Andreas Koch
2005-12-20 14:12:41 UTC
Permalink
Post by Maldona8
Is DirectX the fastest technology for screen drawing?
Usually yes, and usually the most complex.

HOW fast exactly do you have to go?
Does it make a difference if you can draw 100x100 hexagons on
a 1600x1200 screen 10 times per second or 100 times per second?
Maldona8
2005-12-20 15:37:08 UTC
Permalink
Andreas,
well, the idea is to show a nearly real-time neural network classifier doing
the job, so we get data from a multi-channel sensor, at a speed of
5,000-10,000 data points every 10 milliseconds. the neural network map does
classifies the data using the Kohonen algorithm, and I use a wavelet
algorithm to process and find data clusters from the obtained Kohonen map,
it takes nearly 20 milliseconds for math processing, but after all
calculations I have to draw the "current" data map, which takes lot of time
(nearly 20 milliseconds or more), so time resolution for showing the current
data map decreases from an ideal case (every 10 ms) to 50 ms. I believe I
can go down to 10 ms for math processing (I work on that now, math methods
optimizing and possibly Assembler coding), so by decreasing drawing time,
the time resolution for showing neural network response could be improved.
So, achieving a 40 ms resolution will be perfect (just like the PAL video
standard!)
Yes, real time for this experiment is 100 times per second. If we can go
drawing 25 images times per second, that will be enough
Post by Andreas Koch
Post by Maldona8
Is DirectX the fastest technology for screen drawing?
Usually yes, and usually the most complex.
HOW fast exactly do you have to go?
Does it make a difference if you can draw 100x100 hexagons on
a 1600x1200 screen 10 times per second or 100 times per second?
Paul Dunn
2005-12-20 14:26:58 UTC
Permalink
Post by Maldona8
Any web site you recommend for learning to use how to draw, print,
save and load images with DirectX??
Thanks!
DirectX isn't an "image package" solution. The DirectDraw component (or
Direct3D as it is now) basically gives you a mechanism whereby you can
declare "surfaces" which are regions of memory that you can write to. You
can usually gain a handle to that memory, and use the Win32 API graphics
functions to do the drawing. DirectDraw will handle the actual "copying" of
the surface to screen memory, and any effects such as overlays and alpha
channels that you have set up.

I use a TFastDIB as a surface, and instruct DirectDraw to send *that* to
video memory instead of a directdraw surface - but then as I write most of
my display routines in assembly, it's simpler for me to do it that way.

I'll send the FastLIB to you via email - let me know if you need help
installing it, as it's not D5 compatible (I use D5, but it requires some
messing to get working properly).

D.
Maarten Wiltink
2005-12-20 14:59:16 UTC
Permalink
"Paul Dunn" <***@ntlworld.com> wrote in message news:SwUpf.48676$***@newsfe7-gui.ntli.net...
[...]
Post by Paul Dunn
DirectX isn't an "image package" solution. The DirectDraw component
(or Direct3D as it is now) ...
Isn't there a "Direct2D"? That being what the OP needs...

ISTR header files where the IDirectX9 interface inherited from
IDirectX8 (in Delphi terms). I would imagine that this goes all
the way back, and even if a function is advertised to return an
IDirectX9 reference, the IDirectX2 things for example would still
work. So DirectDraw might not have been updated for four years, but
it should still work. It may not be implemented optimally anymore,
though.

Groetjes,
Maarten Wiltink
Paul Dunn
2005-12-20 21:33:09 UTC
Permalink
Post by Maarten Wiltink
[...]
Post by Paul Dunn
DirectX isn't an "image package" solution. The DirectDraw component
(or Direct3D as it is now) ...
Isn't there a "Direct2D"? That being what the OP needs...
Around the time of DirectX 8, M$ decided to deprecate the 2D aspect and no
longer support DirectDraw (your "Direct2D" interface). It is still
supported, but as you say is likely less than optimal now. As the next
version of windows will be strictly 3D acceleration only (seen the demo of
the new windows UI? I'm moving to linux when XP is dead!) I can't see that
DirectDraw will be accelerated above GDI level at all in future.

ISTR that any DirectDraw surfaces used now will use the old DirectX 5
architecture, and not take advantage of any new on-board acceleration your
graphics card has to offer. However, as a method of gaining a pointer
directly to video memory, it's still invaluable if you're willing to do all
your graphics coding by pushing pixels around and not tending to rely on
Borland's intolerably slow TBitmap.Canvas or TBitmap.Scanlines methods.

D.
Maldona8
2005-12-20 22:24:55 UTC
Permalink
no no, for sure, no direct image.canvas drawing at all, now
I am trying now to see how to make the
drawing in memory, and then to play the memory
drawing image into screen using bitblt ()...
for the moment just big headache...
but I believe you guys
Yeah, I agree about discontinued DirectX,
but if M$ has abandoned DirectDraw that means
there is something better around... something they can not compete with
Ronald
Post by Paul Dunn
Post by Maarten Wiltink
[...]
Post by Paul Dunn
DirectX isn't an "image package" solution. The DirectDraw component
(or Direct3D as it is now) ...
Isn't there a "Direct2D"? That being what the OP needs...
Around the time of DirectX 8, M$ decided to deprecate the 2D aspect and no
longer support DirectDraw (your "Direct2D" interface). It is still
supported, but as you say is likely less than optimal now. As the next
version of windows will be strictly 3D acceleration only (seen the demo of
the new windows UI? I'm moving to linux when XP is dead!) I can't see that
DirectDraw will be accelerated above GDI level at all in future.
ISTR that any DirectDraw surfaces used now will use the old DirectX 5
architecture, and not take advantage of any new on-board acceleration your
graphics card has to offer. However, as a method of gaining a pointer
directly to video memory, it's still invaluable if you're willing to do
all your graphics coding by pushing pixels around and not tending to rely
on Borland's intolerably slow TBitmap.Canvas or TBitmap.Scanlines methods.
D.
Paul Dunn
2005-12-20 23:01:03 UTC
Permalink
Post by Maldona8
no no, for sure, no direct image.canvas drawing at all, now
I am trying now to see how to make the
drawing in memory, and then to play the memory
drawing image into screen using bitblt ()...
for the moment just big headache...
Use the supplied TFastIMG for windowed mode.

Then draw to an in-memory surface, say BackDIB, then..

BackDIB.Draw(FastIMG1.Bmp.hDc, 0, 0)

Which wraps the BitBlt() API. If you're using DirectDraw then look at the
fumes example - it simply sets up a DDraw surface and then throws the
surface away, replacing it with a FastIMG's "bits" property. You draw to the
FastDIB, and by doing so you draw to the screen.

Buffer chaining is a different kettle of bananas, though.

D.
Maldona8
2005-12-21 00:34:40 UTC
Permalink
Obi,
how to proceed to install FastLib in Delphi5?
Ronald
Post by Paul Dunn
Post by Maldona8
no no, for sure, no direct image.canvas drawing at all, now
I am trying now to see how to make the
drawing in memory, and then to play the memory
drawing image into screen using bitblt ()...
for the moment just big headache...
Use the supplied TFastIMG for windowed mode.
Then draw to an in-memory surface, say BackDIB, then..
BackDIB.Draw(FastIMG1.Bmp.hDc, 0, 0)
Which wraps the BitBlt() API. If you're using DirectDraw then look at the
fumes example - it simply sets up a DDraw surface and then throws the
surface away, replacing it with a FastIMG's "bits" property. You draw to
the FastDIB, and by doing so you draw to the screen.
Buffer chaining is a different kettle of bananas, though.
D.
Paul Dunn
2005-12-21 01:20:08 UTC
Permalink
Post by Maldona8
how to proceed to install FastLib in Delphi5?
To use a TFastDIB, just add "FastDIB" to your uses clause, and away you go -
assuming that you've set the path to the source correctly in the library
options. You can add other units (FastFX, FastDraw etc) to get at the other
functions available for things like fast antialiased line and circle
drawing, fillrect, gradients etc.

The FastIMG is modified in the version I sent you - the picture property
(which allows you to load bmps to the FastIMG at design time) uses DsgnIntf,
the path to which also needs to be added - should be in
{$DELPHI}\Source\ToolsAPI. This didn't sit well with Delphi 2005 (spit) and
I've not gotten around to re-enabling it since I moved back to Delphi 5. I
don't use the picture property.

I'll dig out a version that has it if you need to be able to load pictures
to it at design time.

To install TFastIMG, just use the Component...Install menu option, and
navigate to FastIMG.pas.

As I say, I just zipped up my install (including all my modifications). If
you want the original version, just let me know.

D.
Jamie
2005-12-21 02:26:31 UTC
Permalink
Post by Maldona8
no no, for sure, no direct image.canvas drawing at all, now
I am trying now to see how to make the
drawing in memory, and then to play the memory
drawing image into screen using bitblt ()...
for the moment just big headache...
but I believe you guys
Yeah, I agree about discontinued DirectX,
but if M$ has abandoned DirectDraw that means
there is something better around... something they can not compete with
Ronald
Post by Paul Dunn
Post by Maarten Wiltink
[...]
Post by Paul Dunn
DirectX isn't an "image package" solution. The DirectDraw component
(or Direct3D as it is now) ...
Isn't there a "Direct2D"? That being what the OP needs...
Around the time of DirectX 8, M$ decided to deprecate the 2D aspect and no
longer support DirectDraw (your "Direct2D" interface). It is still
supported, but as you say is likely less than optimal now. As the next
version of windows will be strictly 3D acceleration only (seen the demo of
the new windows UI? I'm moving to linux when XP is dead!) I can't see that
DirectDraw will be accelerated above GDI level at all in future.
ISTR that any DirectDraw surfaces used now will use the old DirectX 5
architecture, and not take advantage of any new on-board acceleration your
graphics card has to offer. However, as a method of gaining a pointer
directly to video memory, it's still invaluable if you're willing to do
all your graphics coding by pushing pixels around and not tending to rely
on Borland's intolerably slow TBitmap.Canvas or TBitmap.Scanlines methods.
D.
create a Tbitmap..
set the pixelformat property to 8 bit for now.

then set the Width and Height properties

to get the first byte of memory of this bitmap simply
use the MyImagePointer := MyBitmap.Scanline[NUmberOflines-1];
this will give you the memory pointer to the first byte of
memory.
remember that Tbitmaps normally are created upside down.
this is from the old days of slow video monitors and video
cards so that when painting the image to the screen the OS would
paint from the bottom up. this would avoid all the possible
multiple flickers and delays you would get when the video card
was scanning to refresh the video output verses when the
OS was trying to write to the video memory.
at best, you would get only one line of flicker if it happen
to intersect.
since the advent of video memory able to "write" at the
same time of scanning now, this problem has gone away.
--
Real Programmers Do things like this.
http://webpages.charter.net/jamie_5
Maldona8
2005-12-21 00:11:06 UTC
Permalink
Thanks KA1LPA!
I will check your idea as soon as I finish with Paul suggested algorithm.
Ronald
Post by Jamie
Post by Maldona8
no no, for sure, no direct image.canvas drawing at all, now
I am trying now to see how to make the
drawing in memory, and then to play the memory
drawing image into screen using bitblt ()...
for the moment just big headache...
but I believe you guys
Yeah, I agree about discontinued DirectX,
but if M$ has abandoned DirectDraw that means
there is something better around... something they can not compete with
Ronald
create a Tbitmap..
set the pixelformat property to 8 bit for now.
then set the Width and Height properties
to get the first byte of memory of this bitmap simply
use the MyImagePointer := MyBitmap.Scanline[NUmberOflines-1];
this will give you the memory pointer to the first byte of
memory.
remember that Tbitmaps normally are created upside down.
this is from the old days of slow video monitors and video
cards so that when painting the image to the screen the OS would
paint from the bottom up. this would avoid all the possible
multiple flickers and delays you would get when the video card
was scanning to refresh the video output verses when the
OS was trying to write to the video memory.
at best, you would get only one line of flicker if it happen
to intersect.
since the advent of video memory able to "write" at the
same time of scanning now, this problem has gone away.
--
Real Programmers Do things like this.
http://webpages.charter.net/jamie_5
Maldona8
2005-12-20 15:40:12 UTC
Permalink
I can install D6 also, no problem.
BTW, why do you say D5 needs messing to work properly?
For me it works just fine until now...

Let me see the library and how it works
Some examples will be of great help!
Thanks guys! You are really great!
Ron
Post by Paul Dunn
Post by Maldona8
Any web site you recommend for learning to use how to draw, print,
save and load images with DirectX??
Thanks!
DirectX isn't an "image package" solution. The DirectDraw component (or
Direct3D as it is now) basically gives you a mechanism whereby you can
declare "surfaces" which are regions of memory that you can write to. You
can usually gain a handle to that memory, and use the Win32 API graphics
functions to do the drawing. DirectDraw will handle the actual "copying"
of the surface to screen memory, and any effects such as overlays and
alpha channels that you have set up.
I use a TFastDIB as a surface, and instruct DirectDraw to send *that* to
video memory instead of a directdraw surface - but then as I write most of
my display routines in assembly, it's simpler for me to do it that way.
I'll send the FastLIB to you via email - let me know if you need help
installing it, as it's not D5 compatible (I use D5, but it requires some
messing to get working properly).
D.
Maldona8
2005-12-20 17:33:56 UTC
Permalink
I checked out both Graphics32 and FastLIB libraries.
They are both really impressing, fast as a flash!
Personally I prefer FastLIB, 'cause it has really impressive
capabilities to manage graphics at high speed! Wau!
What it has created me an uncomfortable feeling is the IJL15.DLL
library in some FastLIB demos (IJL15.dll is the intel jpeg library).


Thanks guys!
Post by Paul Dunn
Post by Maldona8
Any web site you recommend for learning to use how to draw, print,
save and load images with DirectX??
Thanks!
DirectX isn't an "image package" solution. The DirectDraw component (or
Direct3D as it is now) basically gives you a mechanism whereby you can
declare "surfaces" which are regions of memory that you can write to. You
can usually gain a handle to that memory, and use the Win32 API graphics
functions to do the drawing. DirectDraw will handle the actual "copying"
of the surface to screen memory, and any effects such as overlays and
alpha channels that you have set up.
I use a TFastDIB as a surface, and instruct DirectDraw to send *that* to
video memory instead of a directdraw surface - but then as I write most of
my display routines in assembly, it's simpler for me to do it that way.
I'll send the FastLIB to you via email - let me know if you need help
installing it, as it's not D5 compatible (I use D5, but it requires some
messing to get working properly).
D.
Hans-Peter Diettrich
2005-12-21 04:05:35 UTC
Permalink
Post by Maldona8
DoDi, did you mean, to create a monochrome bitmap
directly in memory and then forcing copy bitmap regions to screen?
I have 100x100 hexagons in the image. Each hexagon has a individual color,
indepently of any other hexagon colors, neighbors, etc.
Not a direct copy to the screen, that will cause flicker. Instead
allocate a buffer bitmap, and BitBlt the monochrome hexagon bitmap into
it, for each of your 100*100 hexagons. Finally copy the completed bitmap
to the screen (canvas). Enabling double buffered display will make the
display persistent, until you replace it by another copy of your buffer
bitmap. Otherwise you'll have to copy all or part of your buffer to the
screen, in the OnDraw event handler of the control or form.
All that will work without DirectX!
Post by Maldona8
Is DirectX the fastest technology for screen drawing?
Only if you use the features of the graphics hardware. In your case this
(most probably) would mean to define a basic hexagon, resident in the
graphics memory(!), so that the copies are created inside the memory on
the graphics card. I have no concrete idea, how DirectX might be used in
your specific case, only some general ideas and hearsay :-(
Post by Maldona8
SO, does it means
1) to use DIB or WMF or EMF to draw something
(100x100 hexagons for example) in a bitmap in RAM memory
2) play the Bitmap memory into Screen memory through VideoCard ASM
instructions or DirectX
After a review of TBitmap and TCanvas I'd suggest the following:
1) Create a hexagon Bitmap with a single hexagon, one for every color.
2) Create a buffer Bitmap for your 100x100 hexagons.
3) Copy the hexagon bitmaps to the buffer bitmap, 100*100 times.
4) Copy the buffer bitmap to the canvas of your form or control.

Use your existing code for constructing the hexagon bitmaps, varying the
Pen.Color.
You can use bitmap.Canvas.Draw for all copy operations. Play with the
CopyMode property (cmSrcPaint?).

Put (4) into the OnDraw event handler of your form or control, and
disable double buffering. Make sure that the handler code does nothing,
as long as no buffer bitmap has been created! (or see my code snippet below)

You may proceed in the following steps:
0) Only paint e.g. 10*10 hexagons, until the code works as it should.
1) Paint polygons directly to the canvas, in the OnDraw handler.
2) ...using previously created hexagon bitmaps instead of polygons.
3) ...paint to a buffer bitmap, copy that bitmap in the OnDraw handler.
Now it should paint as fast as possible, even without DirectX or ASM.
4) Paint the total 100*100 hexagons.

Bonne chançe :-)
DoDi


P.S.: Just tested step 1, using an TImage: it takes about 1 second to
prepare all the 10000 polygons, on my 3 GHz system, using D4. No OnDraw
handler required, the buffer bitmap resides in the TImage.
It takes a bit longer, but looks nice, when a Image1.Refresh is inserted
after every 100 hexagons :-)
Code snippet:

//create new sample
procedure TForm1.Button1Click(Sender: TObject);
begin
//dimension the bitmap - at least once
Image1.Picture.Bitmap.Width := Image1.Width;
Image1.Picture.Bitmap.Height := Image1.Height;
//now draw on the bitmap
PaintHex(Image1.Picture.Canvas); //your task...
//Image1.Refresh; //not required?
end;

//draw single hexagon - simplest version (LineTo on the bitmap canvas)
procedure TForm1.HexPaint(c: TCanvas; x, y: integer; clr: TColor);
begin
c.Pen.Color := clr;
c.MoveTo(x+dx*2, y+dy);
c.LineTo(x+dx*6, y+dy);
...
end;
Maldona8
2005-12-22 06:48:02 UTC
Permalink
DoDi,
That's really great help! thanks for your advices! I will check it out right
now!
Post by Hans-Peter Diettrich
Post by Maldona8
DoDi, did you mean, to create a monochrome bitmap
directly in memory and then forcing copy bitmap regions to screen?
Not a direct copy to the screen, that will cause flicker. Instead
allocate a buffer bitmap, and BitBlt the monochrome hexagon bitmap into
it, for each of your 100*100 hexagons. Finally copy the completed bitmap
Bonne chançe :-)
DoDi
Merci bien ! J'suis très content ! Merci beaucoup! :o)

In my reply to Andreas Koch (20.12.05) I explained about the
task itself and the time resolution for drawing the colored hexagons...
So, 1 second for drawing the whole thing seems to me really a lot...

In my first reply to Bjørge (on 20.12.05) I submitted a Delphi source
code I use to draw a 10x10 hexagon bitmap, with Polygon().
One thing:
I dont know previously the color of each hexagon. It comes out
only after a neural network map (NN Kohonen's Map in my case) has calculated
the weights and actually each hexagon represents the neurons of this neural
network map.
As the map is calculated very fast (I have done something like
the FFT for increasing NN speed), I thought fast drawing the result could
reflect
the activity of the process (experiment with plants) that we try to
monitor...

Anyway, in my PIV 3.2 GHz I succeed to draw the whole thing in 250 ms with
D5
(In principle, every hexagon should be an object with properties and
methods).
Anyway 250 ms is still too much for me, because if I am going to show
a nearly real-time neural network doing its job, then I have to go down in
time resolution up to (at least) 40 - 50 ms.

Your advices are very valuable and interesting,
so I will try to follow your idea to see what happen! thanks! :o)

Ronald
Hans-Peter Diettrich
2005-12-22 19:42:42 UTC
Permalink
Post by Maldona8
Anyway, in my PIV 3.2 GHz I succeed to draw the whole thing in 250 ms with
D5
(In principle, every hexagon should be an object with properties and
methods).
Anyway 250 ms is still too much for me, because if I am going to show
a nearly real-time neural network doing its job, then I have to go down in
time resolution up to (at least) 40 - 50 ms.
You can give a more real-time response, by only updating the changed
hexagons. This would require to remember the display-state in the
hexagon objects, and perhaps a callback procedure to immediately redraw
a changed object on the screen, in the according position.
Post by Maldona8
Your advices are very valuable and interesting,
so I will try to follow your idea to see what happen! thanks! :o)
It was a funny exercise, to quickly find a first solution for your
problem. Now it's up to you to find the real bottlenecks, so that you
don't spend too much time with ineffective optimizations. Keep us
informed or your progress!

DoDi
Maldona8
2005-12-22 23:53:46 UTC
Permalink
Well, have to stop for a while, as I go to see my family in Madrid
hexagon objects, and perhaps a callback procedure to immediately redraw a
changed object on the screen, in the according position.
Unfortunately, almost each hexagon in the neural map is changing, little,
but changing...
However your idea is excellent and I will go on try what happen if terms of
time.
Thanks!
It was a funny exercise, to quickly find a first solution for your
problem. Now it's up to you to find the real bottlenecks, so that you
don't spend too much time with ineffective optimizations. Keep us informed
or your progress!
For sure I will! Thanks for all your efforts and help!

Merry Christmas Dodi!
Merry Christmas to all of you, guys!

Ronald
Francis Burton
2005-12-23 12:17:58 UTC
Permalink
Post by Maldona8
Unfortunately, almost each hexagon in the neural map is changing, little,
but changing...
If the point of having a map displayed is to give the viewer
information about the progress of the algorithm (or some such),
it probably doesn't matter if the graphics are not an =exact=
representation of the program state. So you could probably get
away with not redrawing those hexagons which have changed less
than some delta. For larger values of delta, that may introduce
some "stepping" artefacts. Who knows, though, that might even
improve the perceptual feedback!

Francis
Maldona8
2005-12-23 13:26:07 UTC
Permalink
Fran,
yeah, well, this is not a map that reflect the development of an algorithm.
The idea in this project is more complicated in term or time requirements

I will try briefly to explain it:

The problem:
-------------
We have a multichannel signal we have to screen in order to see the
development of a process
The process is very fast (in terms of microseconds to milliseconds). It
happens for several seconds and
then many other processes start to happen and then it becomes meaningless to
continue monitoring, but the first seconds are very significatives in terms
of valuable information.
We have sophisticated sensors that are able to monitor the process, but the
measured data comes from a huge amount of channels and we have to organize
that information somehow, if we want to understand what's going on.

Solution 1:
-----------
1) fast data AD acquisition, with 10 ms sampling interval
2) Use a SOM (Kohonen Self-Organizing Map) to organize the data
3) Plot the SOM (U-Matrix)

Here we are interested in the evolution of a process, not in the evolution
of an algorithm

Solution 2:
----------
1) Install 100 mini CCD cameras to observe the process
2) Video data processing

Theorem I
It is good to have an interesting research topic as job

Theorem II
after the job it is good to go out with some nice friends and have a good
beer!

Merry Christmas!
Post by Francis Burton
Post by Maldona8
Unfortunately, almost each hexagon in the neural map is changing, little,
but changing...
If the point of having a map displayed is to give the viewer
information about the progress of the algorithm (or some such),
it probably doesn't matter if the graphics are not an =exact=
representation of the program state. So you could probably get
away with not redrawing those hexagons which have changed less
than some delta. For larger values of delta, that may introduce
some "stepping" artefacts. Who knows, though, that might even
improve the perceptual feedback!
Francis
Arash Partow
2005-12-23 23:26:44 UTC
Permalink
This sounds like some kind of nuclear explosion test scenario, the
only differeing
thing is that the time resolution in NETs is in the pico-nanoseconds.
Maldona8
2005-12-24 00:16:48 UTC
Permalink
:o)
hehe!
Post by Arash Partow
This sounds like some kind of nuclear explosion test scenario, the
only differeing
thing is that the time resolution in NETs is in the pico-nanoseconds.
Hans-Peter Diettrich
2005-12-23 15:49:49 UTC
Permalink
Post by Maldona8
-------------
We have a multichannel signal we have to screen in order to see the
development of a process
The process is very fast (in terms of microseconds to milliseconds). It
happens for several seconds and
then many other processes start to happen and then it becomes meaningless to
continue monitoring, but the first seconds are very significatives in terms
of valuable information.
We have sophisticated sensors that are able to monitor the process, but the
measured data comes from a huge amount of channels and we have to organize
that information somehow, if we want to understand what's going on.
Then it might be better to store the information (hexagon colors) about
the first few seconds, for later replay in fast or slow motion, perhaps
for multiple times. The stored information could be presented by a
separate "monitor" program, independently from the real-time processing
in the other programs. Multithreading or multitasking is frequently used
in real time applications.

Otherwise, if the display really should present a real-time "movie", I'd
paint the changes directly on the screen. It shouldn't be a problem, if
some changes of the same hexagons are not painted?
(Then it also might make sense to use DirectX, to write directly to the
video memory).

DoDi

P.S.: Another test, now with stored hexagon bitmaps for every color:
I could paint 9 samples per second, each of 100*100 polygons.
Hint: Image1.Refresh must be used after each sample, to make it visible.

Painting to the canvas of the form, with or without double buffering,
allows for over 20 samples per second, with some flicker. The flickering
certainly could be suppressed, if double buffering and appropriate
enable/disable repaints were used. I just couldn't find the property,
should be something like LockUpdates (not in D4)?
Other graphics cards may not flicker at all?
Maldona8
2005-12-24 00:15:14 UTC
Permalink
DoDi,
in principle your are right,
we can store the data for later processing,
so, we can evaluate the results more slowly.
That way we can evaluate another more sophisticated
and time consuming algorithms for clustering by similarity...
You're absolutely right!
I can not wait to explain that to my boss!

Actually, for data clustering with Kohonen Map
I use a Delphi multithreading component.
But if we take the off-line visualization option
then there is not problem at which speed we draw the map...
Hope my chief accept that idea...
Post by Hans-Peter Diettrich
Then it might be better to store the information (hexagon colors) about
the first few seconds, for later replay in fast or slow motion, perhaps
for multiple times. The stored information could be presented by a
separate "monitor" program, independently from the real-time processing in
the other programs. Multithreading or multitasking is frequently used in
real time applications.
Otherwise, if the display really should present a real-time "movie", I'd
paint the changes directly on the screen. It shouldn't be a problem, if
some changes of the same hexagons are not painted?
(Then it also might make sense to use DirectX, to write directly to the
video memory).
DoDi
I could paint 9 samples per second, each of 100*100 polygons.
Hint: Image1.Refresh must be used after each sample, to make it visible.
It sounds realy good! This is about 111 ms resolution!
Post by Hans-Peter Diettrich
Painting to the canvas of the form, with or without double buffering,
allows for over 20 samples per second, with some flicker. The flickering
certainly could be suppressed, if double buffering and appropriate
enable/disable repaints were used. I just couldn't find the property,
should be something like LockUpdates (not in D4)?
Other graphics cards may not flicker at all?
I found a Lock procedure that applies to GraphicalObject in the Help

procedure Lock;
Description
Blocks other execution threads from using the associated canvas until the
Unlock method is called.
Call Lock in a multithreaded application before using the graphics object in
a section of code that would not otherwise be thread-safe. Lock prevents
other cooperating threads in the application from using the associated
canvas until the Unlock method is called. Calls to Lock can be nested so
that the canvas is not unlocked until the last lock is released.
Because Lock prevents other threads from executing, it can adversely affect
performance. Do not call Lock unless there is a danger that another thread
might interfere with the drawing.
Note: Lock will do nothing unless the drawing surface sets the
OwnerCriticalSection property. TCanvas objects automatically set the
OwnerCriticalSection property when they use graphics objects.

is this Lock the LockUpdates equivalent?
Hans-Peter Diettrich
2005-12-25 05:45:01 UTC
Permalink
Post by Maldona8
DoDi,
in principle your are right,
we can store the data for later processing,
so, we can evaluate the results more slowly.
That way we can evaluate another more sophisticated
and time consuming algorithms for clustering by similarity...
You're absolutely right!
I can not wait to explain that to my boss!
Good luck :-)
Post by Maldona8
I found a Lock procedure that applies to GraphicalObject in the Help
procedure Lock;
Description
Blocks other execution threads from using the associated canvas until the
Unlock method is called.
I was thinking about a different method, preventing Windows from sending
paint messages. Something like the LockWindowUpdate API, but not exactly
that. It depends on your intention and implementation of the painting,
whether such a procedure is required at all.

Une Bonne Année souhaite
DoDi
PATRICK RICHARDOT
2006-01-05 06:32:25 UTC
Permalink
Salut apparament tu comprend le français

ben pour la visualisation toutes façon il faur que tes client soit
honnete ca rime a rien de balancé plus de 50 images seconde meme 25
cest deja largement suffisant pour des humains. A moins que tes client
n en soit pas.

Autrement, pour tes calculs comme dise les autres fait les en tache de
fonds et previent le thred principale qu il doiv faire une mise a jour
quand il le faut. Apres, cest bien plus de l'optimisation de traitement
multitache que booster la partie graphique.

Pour les graphique en fait comme pour tout programme qui doit turbiné
faut le faire seulement quand cest nécessaire et surtout dessine QUE CE
QUI EST VISIBLE A L'ECRAN.

Si Microsoft faisait autrement dans Excel ca serait mille fois plus
lent au moins ...

Bon courage en bonne année ^^
--
Ceci est une signature automatique de MesNews.
Site : http://mesnews.no-ip.com
Bjørge
2005-12-19 08:36:28 UTC
Permalink
Post by Maldona8
Looking for algorithms, source codes for fast drawing routines in
Delphi I have a hexagonal grid of 100x100 hexagons, each hexagon
having its own color.
I need to draw this map in a very very fast way, the faster possible.
What Delphi technology would you recommend to do this job?
Thanks in advance for your help!
No matter what you do, don't do a large number of point/draw operatrions
onto a visible canvas. Do rather create an invisible ("off-screen") bitmap,
do all painting on this one, and copy the entire image onto the visibla
canvas by BitBlt() WinAPI. This is\t as magic as e.g. DirectX, but it speeds
up painting substantially.
--
Bjørge
***@haha_itte.no
Hans-Peter Diettrich
2005-12-19 16:31:59 UTC
Permalink
Post by Bjørge
Post by Maldona8
I need to draw this map in a very very fast way, the faster possible.
What Delphi technology would you recommend to do this job?
Thanks in advance for your help!
No matter what you do, don't do a large number of point/draw operatrions
onto a visible canvas. Do rather create an invisible ("off-screen") bitmap,
do all painting on this one, and copy the entire image onto the visibla
canvas by BitBlt() WinAPI. This is\t as magic as e.g. DirectX, but it speeds
up painting substantially.
You mean something like an explicit "double buffered" option?
What about extending this approach into multiple buffers, which can be
updated independently, and which finally are overlaid into the current
view, as appropriate? Something like different layers, from background
to foreground, each stored and updated in a distinct buffer...

DoDi
Maldona8
2005-12-20 15:47:28 UTC
Permalink
OK Bjørge,
here is the code I use for a simply 10x10 map
Please modify it so it can make use of the
off-screen bitmap with BitBlt functions?

procedure TForm1.Button1Click(Sender: TObject);
const
CellSizeX = 12;
CellSizeY = 12;
var
x0,y0,i,j : integer;
xPoints : array[0..5] of TPoint;
xD : integer;
begin
With Image1.canvas do
begin
xD := (CellSizeY div 4)*3;
For i:=0 to 9 do
begin
For j:=0 to 9 do
begin
x0:=i;
y0:=j;
if (round(y0) mod 2)=0 then
x0:= x0*CellSizeX
else
x0:= x0*CellSizeX + (CellSizeX div 2);
y0 := round(y0*xD);
xPoints[0].x := round(x0+CellSizeX div 2);
xPoints[0].y := round(y0);
xPoints[1].x := round(x0+CellSizeX);
xPoints[1].y := round(y0+CellSizeY div 4);
xPoints[2].x := round(x0+CellSizeX);
xPoints[2].y := round(y0+xD);
xPoints[3].x := round(x0+CellSizeX div 2);
xPoints[3].y := round(y0+CellSizeY);
xPoints[4].x := round(x0);
xPoints[4].y := round(y0+xD);
xPoints[5].x := round(x0);
xPoints[5].y := round(y0+CellSizeY div 4);
Polygon(xPoints);
inc(y0);
end;
end;
end;
end;

Thanks for your help!!!
Ronald
Post by Bjørge
Post by Maldona8
Looking for algorithms, source codes for fast drawing routines in
Delphi I have a hexagonal grid of 100x100 hexagons, each hexagon
having its own color.
I need to draw this map in a very very fast way, the faster possible.
What Delphi technology would you recommend to do this job?
Thanks in advance for your help!
No matter what you do, don't do a large number of point/draw operatrions
onto a visible canvas. Do rather create an invisible ("off-screen") bitmap,
do all painting on this one, and copy the entire image onto the visibla
canvas by BitBlt() WinAPI. This is\t as magic as e.g. DirectX, but it speeds
up painting substantially.
--
Bjørge
Bjorge Sæther
2005-12-21 08:34:04 UTC
Permalink
Post by Maldona8
Post by Bjørge
No matter what you do, don't do a large number of point/draw operatrions
onto a visible canvas. Do rather create an invisible ("off-screen") bitmap,
do all painting on this one, and copy the entire image onto the visibla
canvas by BitBlt() WinAPI. This is\t as magic as e.g. DirectX, but it speeds
up painting substantially.
OK Bjørge,
here is the code I use for a simply 10x10 map
Please modify it so it can make use of the
off-screen bitmap with BitBlt functions?
Eh...well, something must have happened since my last "fast paint"
attempt...maybe something with hardware:
- when I tried to do this opearation on an offscreen bitmap, it turned
out to be some 10% slower !

I'll have to go back to my original sources to see if I have missed
something - but I'm afraid not.



Bjørge
Maldona8
2005-12-21 18:08:52 UTC
Permalink
Dear Bjørge,
please tell me what exactly u was trying to do.
I cannot understand almost nothing from your message
except it was 10% slower... slower than what?
What is your "fast paint" all about?

Hey guys, until now the best solution seems to
be FastLib. Thanks Paul!

Arosh Partow's Graphics32... I am testing your library now... Thanks!

Marteen, please excuse the over-excited Arosh's tone about Graphics32.
I am sure he doesn't mean to bother other people here and he is just being
highly optimistic about the speed of the Graphics32 and fastGEO libraries...

Hey guys, finally I decided to write a short app for testing all of the
"FASTEST"
2D graphics solutions for Delphi to draw the 100x100 hexagons!

Until now we have several candidates:
1) Gordy's FastLib
2) Arosh's Graphics32
3) M$ DirectDraw
4) Scanline method (go figure out how to draw 100x100 hexagons)
5) WinAPI drawing functions --> Offscreen bitmap drawing --> BitBlt () for
screen output

Time resolution will be milliseconds

I dedicated web site can be a good place to see the results of the graphic
speed test.

Peace and Merry Christmas!

Ronald
Post by Bjorge Sæther
Post by Maldona8
Post by Bjørge
No matter what you do, don't do a large number of point/draw operatrions
onto a visible canvas. Do rather create an invisible ("off-screen") bitmap,
do all painting on this one, and copy the entire image onto the visibla
canvas by BitBlt() WinAPI. This is\t as magic as e.g. DirectX, but it speeds
up painting substantially.
OK Bjørge,
here is the code I use for a simply 10x10 map
Please modify it so it can make use of the
off-screen bitmap with BitBlt functions?
Eh...well, something must have happened since my last "fast paint"
- when I tried to do this opearation on an offscreen bitmap, it turned out
to be some 10% slower !
I'll have to go back to my original sources to see if I have missed
something - but I'm afraid not.
Bjørge
Arash Partow
2005-12-21 04:57:59 UTC
Permalink
Hi,

Please feel free to ignore everything everyone on this thread except
me has mentioned. All you need to do is download and install
Graphics32 library. All the routines you want are there, and basically
you're not going to get anything faster anywhere else.

Graphics32 url: http://www.graphics32.org/wiki/

And I get the feeling once you figure out your graphics problems you'll
be wanting to do more complex things that may involve some lite
geometry, so feel free to use FastGEO for that kind of stuff:

FastGEO url: http://www.partow.net/projects/fastgeo/index.html




Arash Partow
________________________________________________________
Be one who knows what they don't know,
Instead of being one who knows not what they don't know,
Thinking they know everything about all things.
http://www.partow.net
Maarten Wiltink
2005-12-21 13:51:10 UTC
Permalink
Post by Arash Partow
Please feel free to ignore everything everyone on this thread except
me has mentioned.
Please feel free to go attempt an anatomically impossible obscenity.
Have you ever considered the possibility that other people might have
useful contributions? Or that DIY solutions can be better that prefab
code, because people _learn_ from finding their own way?

Groetjes,
Maarten Wiltink
Maldona8
2005-12-22 19:18:32 UTC
Permalink
Maarten,
(hope this time I didn't mistaken your name) :o)

sometimes we learn better by example,
by following the logic that others have used to solve a problem,
so looking at the source code of other programmers,
beside its moral value (it develops patience and sense for team work
because finally we have to ask questions),
and beside it is already a difficult exercise (sometimes I dont
understand my own coded source),
it has also a pedagogic value...

I think learning by example is a good thing is we are really interested in
learning
how to do it. The one who is not interested will go out temporary from a
trouble,
but will come again and again asking the same questions each time he/she has
a problem

Cheers and Merry Christmas to all of you out there guys!
Ronald
Post by Maarten Wiltink
Post by Arash Partow
Please feel free to ignore everything everyone on this thread except
me has mentioned.
Please feel free to go attempt an anatomically impossible obscenity.
Have you ever considered the possibility that other people might have
useful contributions? Or that DIY solutions can be better that prefab
code, because people _learn_ from finding their own way?
Groetjes,
Maarten Wiltink
Loading...