 |
BorlandTalk.com Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Don Taylor Guest
|
Posted: Wed May 18, 2005 5:51 pm Post subject: Speed of creating tGraphicControl at runtime |
|
|
Creating at runtime multiple instances of a descendant of tGraphicControl
seems very slow.
I've traced this to the point where the Parent property is set. There's a
chunk of complicated-looking code in in tWinControl.SetParent which is
missed out if csReading in ComponentState, but ComponentState is read-only
so I can't set it in my component.
What's the best way of speeding this up? My components do not need to move
or resize or anything complicated, but I need an awful lot which just sit
there and redraw themselves when necessary.
Thanks,
Don Taylor.
|
|
| Back to top |
|
 |
Don Taylor Guest
|
Posted: Wed May 18, 2005 6:02 pm Post subject: Re: Speed of creating tGraphicControl at runtime |
|
|
Sorry, that should be tWinControl.InsertControl, which tests csReading in
aControl.ComponentState.
|
|
| Back to top |
|
 |
GrandmasterB Guest
|
Posted: Wed May 18, 2005 6:25 pm Post subject: Re: Speed of creating tGraphicControl at runtime |
|
|
"Don Taylor" <don (AT) ctrd (DOT) co.uk> wrote
| Quote: | What's the best way of speeding this up? My components do not need to
move or resize or anything complicated, but I need an awful lot which just
sit there and redraw themselves when necessary.
|
Do you really need actual controls? Try doing it with a single graphic on
your display, and just updating areas of your larger graphic as needed.
Create a structure in your app to track the logic of what graphics goes
where in the big graphic.
|
|
| Back to top |
|
 |
Don Taylor Guest
|
Posted: Thu May 19, 2005 8:44 am Post subject: Re: Speed of creating tGraphicControl at runtime |
|
|
Yep, lots of alternatives considered - unfortunately the appearance and
position of many of these controls have to be calculated (before form
creation) depending on user and application options - a single big bitmap
would be extremely complicated.
Lets face it, for the app I'm developing, VCL controls are absolutely
stonkingly ideal and brilliantly simple to use. It's just a shame the
bridge to Windows GDI is clearly processor greedy. This app is being ported
from BPW 7 where I used similar (but less brilliantly simple) visual
components of my own design. This was much, much faster than Delphi 7, but
I can only generate 16-bit apps with it. We now need 32-bit apps to run on
XP, but we'll have trouble convincing users to upgrade if it clearly runs a
lot slower!
Thanks for your comments.
Don.
"GrandmasterB" <Fizzle (AT) shizzle (DOT) com> wrote
| Quote: | "Don Taylor" <don (AT) ctrd (DOT) co.uk> wrote in message
news:428b80a9$1 (AT) newsgroups (DOT) borland.com...
What's the best way of speeding this up? My components do not need to
move or resize or anything complicated, but I need an awful lot which
just sit there and redraw themselves when necessary.
Do you really need actual controls? Try doing it with a single graphic
on your display, and just updating areas of your larger graphic as needed.
Create a structure in your app to track the logic of what graphics goes
where in the big graphic.
|
|
|
| Back to top |
|
 |
Joe Bain Guest
|
Posted: Thu May 19, 2005 12:58 pm Post subject: Re: Speed of creating tGraphicControl at runtime |
|
|
Don Taylor wrote:
| Quote: | Yep, lots of alternatives considered - unfortunately the appearance
and position of many of these controls have to be calculated (before
form creation) depending on user and application options - a single
big bitmap would be extremely complicated.
Lets face it, for the app I'm developing, VCL controls are absolutely
stonkingly ideal and brilliantly simple to use. It's just a shame
the bridge to Windows GDI is clearly processor greedy. This app is
being ported from BPW 7 where I used similar (but less brilliantly
simple) visual components of my own design. This was much, much
faster than Delphi 7, but I can only generate 16-bit apps with it.
We now need 32-bit apps to run on XP, but we'll have trouble
convincing users to upgrade if it clearly runs a lot slower!
|
Could you post some code. Then we might have better suggestions.
--------------
Joe Bain
www.iegsoftware.com
|
|
| Back to top |
|
 |
Don Taylor Guest
|
Posted: Thu May 19, 2005 1:37 pm Post subject: Re: Speed of creating tGraphicControl at runtime |
|
|
"Joe Bain" <j.b.a.i.n@a.d.d.o.n.s.y.s.t.e.m.s..c.o.m> wrote
| Quote: | Could you post some code. Then we might have better suggestions.
|
Constructor tMyGraphicControl.Create(aOwner: tForm; x, y, w, h: integer);
{override}
Begin
inherited Create(aOwner);
Left := x;
Top := y;
Width := w;
Height := h;
Parent := aOwner; {this takes a relatively long time}
End;
When I say a relatively long time, I mean that if you create a hundred of
these, it might take two or three seconds.
If you miss out the last line, it's virtually instant, although of course
you can't see the created components. It's not the painting slowing it down
either - once created, repainting the form is fairly quick.
Thanks if you can help further.
Don.
|
|
| Back to top |
|
 |
Joe Bain Guest
|
Posted: Thu May 19, 2005 1:41 pm Post subject: Re: Speed of creating tGraphicControl at runtime |
|
|
Don Taylor wrote:
| Quote: | "Joe Bain" <j.b.a.i.n@a.d.d.o.n.s.y.s.t.e.m.s..c.o.m> wrote in
message news:428c8d86$1 (AT) newsgroups (DOT) borland.com...
Could you post some code. Then we might have better suggestions.
Constructor tMyGraphicControl.Create(aOwner: tForm; x, y, w, h:
integer); {override}
Begin
inherited Create(aOwner);
Left := x;
Top := y;
Width := w;
Height := h;
Parent := aOwner; {this takes a relatively long time}
End;
When I say a relatively long time, I mean that if you create a
hundred of these, it might take two or three seconds.
If you miss out the last line, it's virtually instant, although of
course you can't see the created components. It's not the painting
slowing it down either - once created, repainting the form is fairly
quick.
Thanks if you can help further.
Don.
|
Can you show the method where the control is acutally painted.
--
--------------
Joe Bain
www.iegsoftware.com
|
|
| Back to top |
|
 |
Don Taylor Guest
|
Posted: Thu May 19, 2005 1:51 pm Post subject: Re: Speed of creating tGraphicControl at runtime |
|
|
"Joe Bain" <j.b.a.i.n@a.d.d.o.n.s.y.s.t.e.m.s..c.o.m> wrote
| Quote: | Can you show the method where the control is acutally painted.
|
As I said, the painting is not the issue. Even with no painting at all they
still take a long time to create.
Don.
|
|
| Back to top |
|
 |
Joe Bain Guest
|
Posted: Thu May 19, 2005 2:09 pm Post subject: Re: Speed of creating tGraphicControl at runtime |
|
|
I think it is the painting that is taking the time. If you don't set
the parent the control never gets painted the following code takes
250ms to run, but the form takes 3 more seconds to show because of the
painting code.
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls,
Forms,
Dialogs, StdCtrls;
type
TMyButton = class(TButton)
public
Constructor Create(aOwner: tForm; x, y, w, h:integer);overload;
end;
TForm3 = class(TForm)
private
{ Private declarations }
public
constructor Create(AOwner: TComponent); override;
end;
var
Form1: TForm1;
implementation
{$R *.dfm}
{ TMyButton }
constructor TMyButton.Create(aOwner: tForm; x, y, w, h: integer);
begin
inherited Create(aowner);
Left := x;
Top := y;
Width := w;
Height := h;
Parent := aOwner;
end;
{ TForm3 }
constructor TForm1.Create(AOwner: TComponent);
var x,y:integer;
tc:Cardinal;
begin
inherited;
tc := GetTickCount;
for x := 0 to 50 do
for y := 0 to 20 do
TMyButton.Create(self,x*10,y*10,10,10);
showmessage(IntToStr(GetTickCount-tc));
end;
end.
--------------
Joe Bain
www.iegsoftware.com
|
|
| Back to top |
|
 |
Don Taylor Guest
|
Posted: Thu May 19, 2005 2:25 pm Post subject: Re: Speed of creating tGraphicControl at runtime |
|
|
"Joe Bain" <j.b.a.i.n@a.d.d.o.n.s.y.s.t.e.m.s..c.o.m> wrote
| Quote: | I think it is the painting that is taking the time. If you don't set
the parent the control never gets painted the following code takes
250ms to run, but the form takes 3 more seconds to show because of the
painting code.
|
Yes, but it's not the actual contents of the Paint procedure which is slow,
it's whatever Delphi is doing to enable painting on the form for that
control (moving it onto the form if you like). This is not terribly
surprising - clearly there is a lot of hidden maintenance to do - but I was
wondering if anyone knows a way of speeding it up. The performance is
orders of magnitude faster without the VCL encapsulation so clearly it's not
a Windows or hardware limitation.
Don.
|
|
| Back to top |
|
 |
Joe Bain Guest
|
Posted: Thu May 19, 2005 2:45 pm Post subject: Re: Speed of creating tGraphicControl at runtime |
|
|
Then the only thing I could suggest is to do all your drawing to a bmp
and paint it to the form.
--------------
Joe Bain
www.iegsoftware.com
|
|
| Back to top |
|
 |
Don Taylor Guest
|
Posted: Thu May 19, 2005 4:02 pm Post subject: Re: Speed of creating tGraphicControl at runtime |
|
|
I've made a substantial improvement by overriding the parent form's
AlignControls method.
Since my controls don't move, AlignControls is not required.
In the source for tWinControl in Delphi 7 (Controls.pas), InsertControl
calls AlignControl which then calls AlignControls. This reads every
existing control to see if its Align <> alNone. This happens every time you
add a control so the more controls you add, the worse it gets. Adding 400
controls means reading all the Aligns 399+398+397+396...+1 times, even if
they all = alNone. Yuck.
Fortunately, tWinControl.AlignControls is virtual, so it can be overridden
to do nothing. This reduces the time taken to create 400 controls from
1500ms downto 70ms! Well worth doing if no controls use Align.
Don.
"Don Taylor" <don (AT) ctrd (DOT) co.uk> wrote
| Quote: | Creating at runtime multiple instances of a descendant of tGraphicControl
seems very slow.
I've traced this to the point where the Parent property is set. There's a
chunk of complicated-looking code in in tWinControl.SetParent which is
missed out if csReading in ComponentState, but ComponentState is read-only
so I can't set it in my component.
What's the best way of speeding this up? My components do not need to
move or resize or anything complicated, but I need an awful lot which just
sit there and redraw themselves when necessary.
Thanks,
Don Taylor.
|
|
|
| Back to top |
|
 |
Peter Below (TeamB) Guest
|
Posted: Thu May 19, 2005 5:58 pm Post subject: Re: Speed of creating tGraphicControl at runtime |
|
|
In article <428cb881$1 (AT) newsgroups (DOT) borland.com>, Don Taylor wrote:
| Quote: | I've made a substantial improvement by overriding the parent form's
AlignControls method.
|
Not needed, you can simply call the parents DisableAlign when you start
creating your controls, and EnableAlign when you are done.
--
Peter Below (TeamB)
Use the newsgroup archives :
http://www.mers.com/searchsite.html
http://www.tamaracka.com/search.htm
http://groups.google.com
http://www.prolix.be
|
|
| Back to top |
|
 |
Don Taylor Guest
|
Posted: Thu May 19, 2005 6:09 pm Post subject: Re: Speed of creating tGraphicControl at runtime |
|
|
"Peter Below (TeamB)" <100113.1101 (AT) compuXXserve (DOT) com> wrote
| Quote: | Not needed, you can simply call the parents DisableAlign when you start
creating your controls, and EnableAlign when you are done.
|
Thanks Peter, I knew there'd be a simple solution. I've been experimenting
for days. Are there any further ways of speeding up runtime creation?
Perhaps I should RTFM. Except it doesn't quite say "do this to make it
quicker", and sometimes it's hard to track down the time-consuming code,
especially if its in a standard Delphi unit.
BPW used to have a Profiler, which reported timings for whatever blocks of
code you're interested in. Anyone heard of something similar available for
Delphi?
Thanks again,
Don.
|
|
| Back to top |
|
 |
Anders Isaksson Guest
|
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|