Memory usage when hosting a WPF control in a WinForms application

  • Thread starter Thread starter Anthony Meehan
  • Start date Start date
A

Anthony Meehan

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.
 
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
Click to expand...
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:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.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 analysis and dump analysis 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/subscriptions/support/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.
 
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:
(e-mail address removed).

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
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:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.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 analysis and dump analysis 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/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Click to expand...
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:
Click to expand...
Click to expand...
Click to expand...
 
Back
Top