C# Winforms - Rendering Off Screen

[ssc456]

Hey Guys,

I've got this app in Winforms that has lots of user controls, nested within other user controls hosting third party controls like Telerik, Janus etc.

The problem I have is I load say 10 - 15 different controls per panel and then I need to show 1 panel on the screen at a time.

The problem is the controls don't seem to render until I show the panel onscreen, and it's all flicker and slow. (transparent background on them too!).

I've tried drawing the controls off-screen (ie -3000, -3000) and bringing them on, doesn't work, I've tried drawing the controls on a hidden panel, doesn't work. I've tried adding the controls to a panel and doing a DrawToBitmap doesn't work, double buffering is switched on for everything.

Any ideas?

I know ideally I should be using WPF and not Winforms but the whole app has already been written and i'm reluctant to re-write.

 

[iPwn]

If you compile the application and run as Stand Alone, do you still see those issues or is it only when run as debug through the IDE? Which IDE are you using?

 

[ssc456]

If you compile the application and run as Stand Alone, do you still see those issues or is it only when run as debug through the IDE? Which IDE are you using?

Unfortunately yes I still get laggy rending when it has been compiled as release and / or producing a setup file and running on a different PC all together.

I'm using MS VS2012 primarily but ran it on VS 2010 and 2013.

 

[iPwn]

Care to share a code snippet from one of the hidden panels?

 

[ssc456]

Errrrm what exactly are you looking for?

We are talking thousands and thousands of lines of code.

Let me give a little more detail.

I have a WPF Grid, Being hosted on a Winforms Form. The WPF Grid is hosting Winforms User Controls. . . . . The Winforms User controls are either hosting other user controls or third party controls.

I know, nasty way to do it.

But it's not a simple app, I guess the whole thing could have been written in WPF but it was solely a Winforms App originally, we changed it to a WPF Grid to enable scaling on various resolutions.

 

[root]

so it's the time taken to render that's slowing things down.

have you tried rendering everything first as a huge mess and then hiding it? (not off screen or on a hidden panel, but where it actually needs to be?


your last option, (and probably best) is to take your own advise.

"we probably could have written it different, but tried to convert between different mechanisms"

I the WPF code doesn't have to host the winforms code, then take away a large and complex layer.

 

[ssc456]

so it's the time taken to render that's slowing things down.

have you tried rendering everything first as a huge mess and then hiding it? (not off screen or on a hidden panel, but where it actually needs to be?


your last option, (and probably best) is to take your own advise.

"we probably could have written it different, but tried to convert between different mechanisms"

I the WPF code doesn't have to host the winforms code, then take away a large and complex layer.

Thanks Root,

We are exploring a couple of options at the minute.

1) Is we do as you say, we accept the fact that the first 30 seconds or so is going to be a mess while we render X number of different screen layouts with different controls in a visible way. Then hide them all and show them 1 at a time. We have done this and it does work very well, the flaw is 2 fold, 1 - The obvious 30 second load time at the start and 2 - The screen layouts can be changed by the customer, many not for months at a time but others on a daily basis. But it is still a good step forwards.

2) My colleague has found a bit of copy n paste jobby code from Google which seems to override some default .net function and says don't show me until I am fully painted (only works in Basic themes, but that's not the end of the world). This works again 95% of the way, it's good and it's taken the couple of second rendering time down to less than a second, but it's still noticeable.

So I think a combination of both of these methods may get us to where we are satisfied. In that the initial load may be messy as we render all different screen layouts and controls on screen, then hide them.
Then we begin displaying 1 screen at a time and just re-bind the data as required (which doesn't require re-painting even if it changes the visuals) or if it does the control is smart enough to do it in a very efficient way.
Finally we only ever re-draw the screen if we detect a change to the layout and in which case there will be a small render time but that will be less than a second and hopefully this will only happen on average once a week?

I have suggested that as a long term plan it is re-written in a different language, perhaps keeping Winforms as the base with C# .net but the controls and screens being Flash that we can pass data to from the .net and tell when to load and to enable us some better and smoother animation or maybe just WPF. It's something we need to discuss if we are going to progress further.