>Thanks. That helps a lot. I found the performence
killer. This problem
>comes from the textbox control. I could avoid most
of the problems by
>changing my new code. But this textbox control is a
real performence
>killer, because it draws each character
separately.
Unless we have a working DrawString, there is no way
to make one call to DrawString
with all the text and correctly word wrap, draw
background of selection etc.
Ill change this once DrawString is working. At
the moment TextBox
would obviously be slow..
>The other think I was
>surprised is the fact
that the tabstrip control calls most of measuring
>stuff at start. For
this it uses all tabs not only the tab it views
>currently. Is this realy
necessary? I think this causes the long startup
>of the FormTest
sample.
The actual text in the tabs need to be measured each
and every time the size
of the TabControl is changed, if any of the text is
changed, or if any of the
properties that affect the tab layout change. These
all affect the size of the area
we have to draw the child controls on, so
this is necessary.
I would need to have another look, but its likely that
the controls are layed out
by control.cs after they are created. The controls
that need to measure string in
order to layout would do so. This is the
way Microsoft does it. However this may
be a candidate for later optimization.
I think its very important to get our implementation
quicker than Microsofts.
At the moment our implementation is definitely quicker
than Microsofts on windows
with the exception of the textbox draw.
One of the things on the cards before 1.0 release
would be a couple of weeks of perf
only work. For now though,
I think we should focus on the most significant otimization
and