speeding up form display/repaints in MDI apps

  • Thread starter Thread starter Sarah Smith
  • Start date Start date
S

Sarah Smith

Hello,

I am a bit of a newbie to VB.NET, but not totally new. I took the
plunge recently and decided (along with my colleagues), to try to
convert/port a VB6 client/server app to .Net.

(I'm not using any upgrade tools, I'm just re-writing).

I have be learning/testing .net with SDI type forms and now I'm
actually working on the conversion, I'm starting to worry that VB.net
is just too slow to be useful. (And I'm coding on a good machine too:
P4/2600/512).

I had started out using some nice graphical buttons, and form and
panel colors that I thought would be more appealing than the standard
battle-ship-gray, but now I think this could be affecting the display
speed adversely.

Changing to and from, and opening new windows from the MDI main menu
is quite slow, but some windows do not repaint properly when other
windows have been closed, or selected or moved. Sometimes leaving an
ugly mess on the screen.

Would it be better to stop using any other color schemses than the
standard windows system colors, and drop graphical buttons and labels?

Are there any smart tricks to make things a little snappier?

-Sarah.
 
Hi Sarah,

I haven't had this experience and I've been coding in vb .net for almost 2
years now. I do have a stronger system than you do (gig ram), and you
didnlt mention your op sys (I'm using xp pro), but that really shouldn't be
that significant.

I'd recommend you stop using other color schemes and use only xp visual
styles (if you have xp) to see if this doesn't change matters. Also, are
your forms loading lots of data on start up of a form? (eg, comboboxes
loading thousands of rows, etc), although this ordinarily also should not be
a big deal.

HTH,

Bernie Yaeger
 
I'd have to agree with Bernie here, the only time I've had problems on
repaints is when I'm working with an incredibly large amount of data, or I
have leaky controls (which is afterall still possible in .NET *cough*
Component One *cough*) it depends how the control is painted.

Are you using the controls that came with .NET or a 3rd party component?

-CJ
 
You're right on the money.

My dev-system is a a notebook with 512mb RAM. that's not an issue
because the RAM isn't being used up, and there's no swapping going on.

But ... the main form does have several controls, including 2 DBGrids
from C1 :-)

I fully expect the load event to be a bit sluggish when it is adding
items to a Combo Box and making a couple of calls to an SQL server to
populate the grids - but - it's after the screens are drawn and ready
that covering them with other windows results in slow, blocky screen
updates.

I have now removed all graphical buttons and background colors and I
can see it has helped a little, but the Visual performance is still
comparable to, or worse than a Java app. (When compared to VB5,6 or
VC++).

I am using Win2000 sp4 on the dev machine, but the app will be
deployed on XP and 2000.

I guess I was hoping this was a well know issue that has had a lot of
people pulling their hair out, but also finding smart work-arounds
that have helped improve the visual performance.

S.
 
You're right on the money.
Click to expand...

Sadly, I wish I wasn't. =)
My dev-system is a a notebook with 512mb RAM. that's not an issue
because the RAM isn't being used up, and there's no swapping going on.

But ... the main form does have several controls, including 2 DBGrids
from C1 :-)
Click to expand...

And that will do it. We use some C1 stuff here, but I've been working on
slowly migrating out of it. I have never seen worse programming in my life.
It straight up sickens me to see that Microsoft is promoting the C1 Suite
with the VBR Kit as well as well as giving them a spot on their tech
highlights.

We have found the C1 controls to be INCREDIBLY slow at loading, causing
anywhere from a 10-50 (yeah, 50) second delay between opening forms. Where
using normal controls take anywhere from 1-7 seconds...

Their tech support could be compared to that of an 8 year old autistic
child. Sometimes they will answer you, but its mainly whenever they feel
like it. It's an American company that appears to outsource all there work
offshore, in particular a Russian software house that doesn't have a lot of
talent and even less support of their product. Then have the audacity to
ask for thousands of dollars for their products. ($400 USD for a grid? Cmon
now...)

I was most interested in C1 because of their O/R Mapper and data access
model. Theoretically the idea is great, a uniform data access layer that
can easily be expanded from 2 to N tiers with a simple property because of
remoting. However, the implementation is buggy and quirky with absolutly no
thought of the end user.

The express components are the worst, which is what I am spending today
replacing, they modelled it after ADO 2.x, but tried to wrap the ADO.NET
components inside of it leading to numerous problems (mainly memory)
especially when trying to clear datasets. Clear methods don't work and data
just gets lost. Ask for support, they wont give it to you.

Ok, I'm done b***hing.

As for comparable to a Java app... Yeah... that is apparent... In some
instances I think the java apps are faster. And you have more control, in
C1 there is very little error checking, you set a property, it resets
itself, no real good reason to it... just sets it back, then after
researching it for awhile you find out why...

Good luck and hope I could help. Try to reduce the number of C1 controls
you use, don't use express tables and limit your data loads, or start it up
on a new thread as to not hurt your users UI experience as much.

HTH,
CJ
 
Well, I'm glad it's not just me, and that perhaps, I can someday drop
the C1 grid entirely and see some more improvements.

But isn't the Data Grid that ships with VS also made by C1 (formerly
Apex)?

Can you recommend any other grids? (I use the Printing features a
lot).

About the last bit you wrote ... can you create instances of MDI Child
forms in separate threads? If so, does doing this help performance?

S.
 
Sarah Smith said:
Well, I'm glad it's not just me, and that perhaps, I can someday drop
the C1 grid entirely and see some more improvements.

But isn't the Data Grid that ships with VS also made by C1 (formerly
Apex)?
Click to expand...

Not sure on that one... If so its the most toned down version I've ever
seen.
Can you recommend any other grids? (I use the Printing features a
lot).
Click to expand...

I only use grids for displaying data, I honestly don't like grids that much,
I know others do.. So I'm not the best one to ask. I like Assetta because
of the column styles, there is also Jan Tielnans (sp?) extended data grid,
which is pretty useful according to most, but I never got it to work and
after several emails to Jan himself with no response I gave up.
About the last bit you wrote ... can you create instances of MDI Child
forms in separate threads? If so, does doing this help performance?
Click to expand...

Of course you can. As for helping performance, it doesn't necessarily do
that, but it does give the user the feeling that it does. =)
 
Can you recommend any other grids? (I use the Printing features a
lot).
Click to expand...
the infragistics ultra grid should have all you need but i haven't used it
(jet) the other components do w they have to do no probs w them.
http://www.infragistics.com/products/grids.asp?sec=1
Printing and Print Preview: Provide the convenience of hard copies for
displayed data. Customization of the printed output is achievable through
the DrawFilter interface.

but like i said thats w they say ;p

eric
About the last bit you wrote ... can you create instances of MDI Child
forms in separate threads? If so, does doing this help performance?
Click to expand...
it should :) if 1 thread has a lot of work the others can still function.
 
Hi All,

OK, I have to take some issue with the C1 bashing. The C1 true db grid is
by far the best on the market, has features no one offers. Yes, there are
bugs, but it has been improving steadily. I use it extensively and my
clients couldn't be happier.

If you load a table with more than, say, 50,000 rows, perhaps 20 cols wide,
it will take 30 - 45 seconds to load; once loaded, however, it's pretty
quick.

I load large tables - 150,000 - with a progressbar which first hides the
grid until it's fully updated.

Just my 2 cents.

Bernie
 
Thanks for all of the comments. I will go on with .Net, but I will be
careful too. Just when I was getting to like the new graphical
features of the controls and the system.drawing name space, I have
decided to pull it all out again, and go for the boring battle-ship
gray and standard buttons of regular Windows programs. It's just too
heavy. (Imagine trying to use a large app like MS Word written in .net
- yuk).

Sorry Bernie, if we were a little hard on the Grid - I have also used
True DBGrid for a long time (since the Apex COM version 6.0c) and
you're right, the feature set of TDBGrid is hard to beat, and like
wise hard to do without.

But ... I still contend that VB6 and the older grid were much faster.

I do like the massive name spaces and libraries that the .Net
framework offers, but it does seem an awful lot like an "MS" Java
system to me.

Actually, because the code you write in VB.NET, or C# is translated to
MSIL and compiled at runtime (--am I right here?--) that too sounds a
lot like the Java 'bytecode' way of doing things. Why don't SUN/Java
make a byte code compiler for other languages? Just a thought.

Has anyone done any performance testing on VB.net vs. Java?

Thanks,

S.
 
Sarah Smith said:
Thanks for all of the comments. I will go on with .Net, but I will be
careful too. Just when I was getting to like the new graphical
features of the controls and the system.drawing name space, I have
decided to pull it all out again, and go for the boring battle-ship
gray and standard buttons of regular Windows programs. It's just too
heavy. (Imagine trying to use a large app like MS Word written in .net
- yuk).

Sorry Bernie, if we were a little hard on the Grid - I have also used
True DBGrid for a long time (since the Apex COM version 6.0c) and
you're right, the feature set of TDBGrid is hard to beat, and like
wise hard to do without.

But ... I still contend that VB6 and the older grid were much faster.
Click to expand...

Microsoft admits that .NET is "slower" in some aspects. 1 is that you can
only have a max of 50% of the CPU at a time. But they contend the
performance hits are justified by RAD functionality and massive amount of
libraries that do exist. =)

I think a lot of UI stuff used to be a lot faster. but more headaches to
deal with.

I admit TrueDB Grid is a good product, but its also a long standing product
too. C1 introduced a buttload of new components recently, most of which
have features to keep you interested, but the lack of support and bug fixes
hardly justifies the cost of these.

For example, C1 Report Writer. Can import Crystal, which is great for the
Web because its a much more simple component to setup on shared hosting
environments... however, it hardly works, can't do 1/1000000 of the
functionality. Same with DataObjects.NET Good features, good ideas, but
just not ready...


I do like the massive name spaces and libraries that the .Net
framework offers, but it does seem an awful lot like an "MS" Java
system to me.
Click to expand...

Heh... sorta.
Actually, because the code you write in VB.NET, or C# is translated to
MSIL and compiled at runtime (--am I right here?--) that too sounds a
lot like the Java 'bytecode' way of doing things. Why don't SUN/Java
make a byte code compiler for other languages? Just a thought.
Click to expand...

Well, compiled intermidiate code is interpreted at runtime. Yes, it is very
much like Java in that sense except platform specific (java breaks the whole
unix boundry thing, but Shelton is on aproject right now to fix
that...go-mono)
 
Back
Top