Thanks for all the work on this.  I think I am starting to understand why this is impacting a WPF application that only uses IG/winforms in a limited way (to bring up stand-alone winforms forms).

The "AutoSize" stuff you had mentioned is not something that we did deliberately.  A lot of our legacy IG/winforms must have that property set to the default, which is why we see the performance issues.

In a WPF app there are always number of initialization/bootstrapping steps, and I suppose that this "BeginGraphicsCaching" stuff will need to be added in there somewhere as well.  However, I wish there would have been an IG blog or something to like that to point the way.  It doesn't seem that this issue is as well-known as it should be.   On my end, I'll probably end up creating a class that I can introduce in my prism bootstrapping or in the app.xaml resource dictionary.

I'll try to ask my question in a more straight-forward way. 

Why is it that a run-of-the-mill winforms application doesn't need to manually call the Infragristics BeginGraphicsCaching() method?  At what point does this IG method get called in an implicit way from a winforms application,  and what is the reason why that it is *not* happening in the example I attached? (Thereby making it my responsibility.)

So what I'm hearing is that you fully endorse the "pixie dust" work-around (calling Infragistics.Win.DrawUtility.BeginGraphicsCaching();).

Your explanation is somewhat helpful.  Every developer has experience with software that runs slower on the first pass and subsequently better afterwards.  Two things that are still unclear and unconvincing in your response are  :

(1) Why is it my responsibility to optimize your winforms control performances by calling obscure static methods - can't your own stuff do that?  Is there an IG component I can add to the form, or a base class that my form can be derived from which will put this responsibility back on you?, and

(2) You vastly under-state the impact of not calling BeginGraphicsCaching().  Your response seems to imply that the *same* negative impact on performance is seen whether I call it manually or whether you call it implicitly.  The fact of the matter is, if it is left up to you, your IG controls seem to create and destroy large numbers (dozens/hundreds) of "graphics caching" objects during the initialization of the form.

IE. if I totally eliminate my one-time initializing call to SprinkleInfragisticsPixieDust() and change the loop to call it repeatedly as follows:

for(int i = 0; i < 50; i++)

{

Infragistics.Win.DrawUtility.BeginGraphicsCaching();

OpenEditRunWindow();

Infragistics.Win.DrawUtility.EndGraphicsCaching();

}

... then this will still run far faster than a loop that omits Begin/End graphics caching.  Presumably I'm doing the same thing explicitly that you would be doing implicitly.  This really doesn't make sense to me.  It is more reasonable to expect that the performance overhead should have been the same for each time the winforms Form is displayed, whether the responsibility for calling BeginGraphicsCaching is left up to me (to be done explicittly) or to you (to be done implicitly).  This goes back to question (1), is there something that can be done with this form in order to make your implicit initialization of BeginGraphicsCaching work better than it is now (or at least as well as if I am calling these static methods explicitly).

I'm not a big fan of my current approach (SprinkleInfragisticsPixieDust) and would like some more guidance.

Hi,

Thank you for the provided sample. I have investigated it and here is what I found.

Because the form that is opened contains our WinForms controls they create and cache a graphics object. Again in some circumstances this may be from a fallback form, because the control handles still haven’t been created. Then, when you close the form, all the Infragistics WinForms controls that you have created are destroyed. At this point we have no way to know if the application would be using our controls anymore, so we are forced to dispose the cached graphics, as otherwise we can create memory leak. This cycle happens each time you open and close a form.

However, when you add the call to BeginGraphicsCaching, it basically has the effect of saying don’t dispose the graphics object until I call the corresponding EndGraphicsCaching method. In that case we don’t dispose the cached graphics after the form is closed, because someone else has cached the graphics and it is now their responsibility to release it. The end result is that the first time the form shows the time is the same as without calling BeginGraphicsCaching. However, after that, since we don’t dispose and recreate anything, the process is much faster.

So because in your application each time all our WinForms controls are created and then destroyed numerous times, it is best to call the BeginGraphicsCaching method in order to notify our framework that you will keep using our controls. Also make sure to have the corresponding EndGraphicsCaching method call in order to dispose the cached graphics once you are done with our controls.

Also while the issue that you have linked looks similar to this one, it isn’t the same. It is related to improvements in our AutoSizing logic. While they are in place, again the main issue here is that our controls are created and destroyed multiple times.

Hopefully my explanation is clear enough. Let me know if you have any additional questions.