Memory usage when hosting a WPF control in a WinForms application - DOTNET

Hi Anthony,

I have searched in our internal database and found a similar issue in it.

The issue recorded in our database describes that over 20MB of memory is
used when resizing a form with a docked ElementHost.

The root cause of this issue is that as the ElementHost is resized, a
BitmapSource is recreated to change the size of the ElementHost and this
will use up a lot of space on the managed heap until GC. Also, Winforms
hosting WPF will have a larger foot print than just a Winforms application
because the WPF libraries will need to be loaded as well, in addition to
the overhead of interop-ing between the two.

It points out that this behavior is by design.

> The WinForms application has a tab-based interface, so the user quite
often has a number of these ElementHost controls open at once, and opens
and closes them frequently.

Do you mean that the ElementHost is contained in a TabControl on the form?
If so, I suggest that you don't use TabControl on the form because it will
use up a lot of memory especially when there're a lot of controls within
the tab pags of it.

You can add several Panel controls instead and add the ElementHost on one
of the Panel controls. To mimic the behavior of a TabControl, switch among
the Panel controls by making only one of the Panel controls visible at one
time.

Hope this helps.
If you have any question, please feel free to let me know.

Sincerely,
Linda Liu
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msdnmg@microsoft.com.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project ****ysis and dump ****ysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Hi Linda,

Thanks for looking into this for me. Unfortunately we must keep a separate
ElementHost for every open tab in our application. This is because each
ElementHost has a RichTextBox in it which must maintain its own undo/redo
history. It would be a pretty ordinary user experience if you lost your undo
just because you changed tabs.

I'm guessing there is no way that we can prevent the BitmapSource from being
created? eg, turning off double buffering?

Many thanks,


Anthony.

"Linda Liu[MSFT]" wrote:

> Hi Anthony,
>
> I have searched in our internal database and found a similar issue in it.
>
> The issue recorded in our database describes that over 20MB of memory is
> used when resizing a form with a docked ElementHost.
>
> The root cause of this issue is that as the ElementHost is resized, a
> BitmapSource is recreated to change the size of the ElementHost and this
> will use up a lot of space on the managed heap until GC. Also, Winforms
> hosting WPF will have a larger foot print than just a Winforms application
> because the WPF libraries will need to be loaded as well, in addition to
> the overhead of interop-ing between the two.
>
> It points out that this behavior is by design.
>
> > The WinForms application has a tab-based interface, so the user quite
> often has a number of these ElementHost controls open at once, and opens
> and closes them frequently.
>
> Do you mean that the ElementHost is contained in a TabControl on the form?
> If so, I suggest that you don't use TabControl on the form because it will
> use up a lot of memory especially when there're a lot of controls within
> the tab pags of it.
>
> You can add several Panel controls instead and add the ElementHost on one
> of the Panel controls. To mimic the behavior of a TabControl, switch among
> the Panel controls by making only one of the Panel controls visible at one
> time.
>
> Hope this helps.
> If you have any question, please feel free to let me know.
>
> Sincerely,
> Linda Liu
> Microsoft Online Community Support
>
> Delighting our customers is our #1 priority. We welcome your comments and
> suggestions about how we can improve the support we provide to you. Please
> feel free to let my manager know what you think of the level of service
> provided. You can send feedback directly to my manager at:
> msdnmg@microsoft.com.
>
> ==================================================
> Get notification to my posts through email? Please refer to
> http://msdn.microsoft.com/subscripti...ult.aspx#notif
> ications.
>
> Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
> where an initial response from the community or a Microsoft Support
> Engineer within 1 business day is acceptable. Please note that each follow
> up response may take approximately 2 business days as the support
> professional working with you may need further investigation to reach the
> most efficient resolution. The offering is not appropriate for situations
> that require urgent, real-time or phone-based interactions or complex
> project ****ysis and dump ****ysis issues. Issues of this nature are best
> handled working with a dedicated Microsoft Support Engineer by contacting
> Microsoft Customer Support Services (CSS) at
> http://msdn.microsoft.com/subscripti...t/default.aspx.
> ==================================================
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
>

Hi Anthony,

Thank you for your prompt reply!

The resolution of the similar issue recorded in our internal database is
just waiting for the garbage collector to collect the no longer needed
BitmapSources.

Disabling double buffering can decrease memory usage in a sense, but it
won't prevent the BitmapSource from being created.

To make garbage collector work more efficiently, I suggest that you dispose
objects by calling the Dispose method if they have as soon as you won't use
them any more and then set the objects to null or Nothing.

Hope this helps.
If you have any question, please feel free to let me know.

Sincerely,
Linda Liu
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msdnmg@microsoft.com.

This posting is provided "AS IS" with no warranties, and confers no rights.

Hello Anthony,

I'm currently having the same problem of the array of bytes resting in the memory after disposing the ElementHost.
I tried to manipulate the dispose, but no success.
Did you ever find a way to solve this problem?

Kind regards
Piekop

> On Tuesday, March 18, 2008 10:45 AM ant7 wrote:

> Hi,
>
> We are using the ElementHost control to host a WPF control (which is mainly
> a subclassed WPF RichTextBox control) within our WinForms application. The
> WinForms application has a tab-based interface, so the user quite often has a
> number of these ElementHost controls open at once, and opens and closes them
> frequently.
>
> The problem we are seeing is that the application is using a large amount of
> memory, and it appears to be the ElementHost control causing the problem.
> When running CLR Profiler, we can see that a large amount (ie tens of
> megabytes) of Byte[] data is generated by the ElementHost.
>
> Is this a known issue? Users are eventually receiving OutOfMemoryException
> exceptions in production after extended use.
>
>
> Thanks,
>
> Anthony.


>> On Wednesday, March 19, 2008 3:41 AM v-lli wrote:

>> Hi Anthony,
>>
>> I have searched in our internal database and found a similar issue in it.
>>
>> The issue recorded in our database describes that over 20MB of memory is
>> used when resizing a form with a docked ElementHost.
>>
>> The root cause of this issue is that as the ElementHost is resized, a
>> BitmapSource is recreated to change the size of the ElementHost and this
>> will use up a lot of space on the managed heap until GC. Also, Winforms
>> hosting WPF will have a larger foot print than just a Winforms application
>> because the WPF libraries will need to be loaded as well, in addition to
>> the overhead of interop-ing between the two.
>>
>> It points out that this behavior is by design.
>>
>> often has a number of these ElementHost controls open at once, and opens
>> and closes them frequently.
>>
>> Do you mean that the ElementHost is contained in a TabControl on the form?
>> If so, I suggest that you don't use TabControl on the form because it will
>> use up a lot of memory especially when there're a lot of controls within
>> the tab pags of it.
>>
>> You can add several Panel controls instead and add the ElementHost on one
>> of the Panel controls. To mimic the behavior of a TabControl, switch among
>> the Panel controls by making only one of the Panel controls visible at one
>> time.
>>
>> Hope this helps.
>> If you have any question, please feel free to let me know.
>>
>> Sincerely,
>> Linda Liu
>> Microsoft Online Community Support
>>
>> Delighting our customers is our #1 priority. We welcome your comments and
>> suggestions about how we can improve the support we provide to you. Please
>> feel free to let my manager know what you think of the level of service
>> provided. You can send feedback directly to my manager at:
>> msdnmgatmicrosoftdotcom.
>>
>> ==================================================
>> Get notification to my posts through email? Please refer to
>> http://msdn.microsoft.com/subscripti...ult.aspx#notif
>> ications.
>>
>> Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
>> where an initial response from the community or a Microsoft Support
>> Engineer within 1 business day is acceptable. Please note that each follow
>> up response may take approximately 2 business days as the support
>> professional working with you may need further investigation to reach the
>> most efficient resolution. The offering is not appropriate for situations
>> that require urgent, real-time or phone-based interactions or complex
>> project ****ysis and dump ****ysis issues. Issues of this nature are best
>> handled working with a dedicated Microsoft Support Engineer by contacting
>> Microsoft Customer Support Services (CSS) at
>> http://msdn.microsoft.com/subscripti...t/default.aspx.
>> ==================================================
>> This posting is provided "AS IS" with no warranties, and confers no rights.


>>> On Wednesday, March 19, 2008 5:16 AM ant7 wrote:

>>> Hi Linda,
>>>
>>> Thanks for looking into this for me. Unfortunately we must keep a separate
>>> ElementHost for every open tab in our application. This is because each
>>> ElementHost has a RichTextBox in it which must maintain its own undo/redo
>>> history. It would be a pretty ordinary user experience if you lost your undo
>>> just because you changed tabs.
>>>
>>> I'm guessing there is no way that we can prevent the BitmapSource from being
>>> created? eg, turning off double buffering?
>>>
>>> Many thanks,
>>>
>>>
>>> Anthony.
>>>
>>> "Linda Liu[MSFT]" wrote:


>>>> On Friday, March 21, 2008 3:28 AM v-lli wrote:

>>>> Hi Anthony,
>>>>
>>>> Thank you for your prompt reply!
>>>>
>>>> The resolution of the similar issue recorded in our internal database is
>>>> just waiting for the garbage collector to collect the no longer needed
>>>> BitmapSources.
>>>>
>>>> Disabling double buffering can decrease memory usage in a sense, but it
>>>> won't prevent the BitmapSource from being created.
>>>>
>>>> To make garbage collector work more efficiently, I suggest that you dispose
>>>> objects by calling the Dispose method if they have as soon as you won't use
>>>> them any more and then set the objects to null or Nothing.
>>>>
>>>> Hope this helps.
>>>> If you have any question, please feel free to let me know.
>>>>
>>>> Sincerely,
>>>> Linda Liu
>>>> Microsoft Online Community Support
>>>>
>>>> Delighting our customers is our #1 priority. We welcome your comments and
>>>> suggestions about how we can improve the support we provide to you. Please
>>>> feel free to let my manager know what you think of the level of service
>>>> provided. You can send feedback directly to my manager at:
>>>> msdnmgatmicrosoftdotcom.
>>>>
>>>> This posting is provided "AS IS" with no warranties, and confers no rights.