Partilhar via

WPF 3.5 SP1 Performance on Tablet & Touch-enabled machines

  • Artigo

Some customers reported performance issues and general sluggishness on Tablet & Touch-enabled machines with their WPF 3.5 SP1 applications. This is especially noticeable during scrolling if the application comprise of many visual elements.

The root cause is that Accessibility clients need to collect UIAutomation information in order interact with applications. This in turn causes WPF to fire UIAutomation events at the end of each layout.
The current WPF implementation (.NET 3.5 SP1 or earlier, but not .NET 4 RC or later) for this scenario is not as optimal since WPF walks every element in the application tree and checks if it need to fire automation event.

Depending on the machine speed and how many elements are in the application visual tree, this can be CPU consuming and cause sluggishness in your app when it needs to do layout.

The issue is mostly noticeable on Tablet and other touch-enabled machines and not on other machines, because TabTip.exe (the “Tablet PC Input Panel”) is an Accessibility client which collects UIAutomation from your WPF app and it is always running by default on all Tablet /touch-enabled machines.

This scenario will be much improved in .Net 4 and we are still looking on how to help .Net 3.5 SP1 customers, so stay tuned.

What can you do in your .Net 3.5 SP1 app in the meantime ?

1. To verify your perf issue is related to this, you can install latest NET 4 RC build and verify the issue is gone (see below).
If the perf issue gone and you are still confident it is not related to other issues:

2. Consider disabling Accessibility and UIAutomation for your app.
    One good example on how to that is to look at the implementation in the WPF Fishbowl Facebook application.
    You can download sources from here: https://fishbowl.codeplex.com/ . 
    The app basically disables accessibility by adding these lines of code:

        private class _FakeWindowsPeer : WindowAutomationPeer

        {

            public _FakeWindowsPeer(Window window)

                : base(window)

            { }

            protected override List<AutomationPeer> GetChildrenCore()

            { return null; }

        }

        protected override AutomationPeer OnCreateAutomationPeer()

        { return new _FakeWindowsPeer(this);  }

 

Important Note: This workaround will also disable accessibility for your app so this workaround is not encouraged. Your app will not be available to any Accessibility clients , such as Screen Reader or automation tests, so only do so if you must and cannot for example simplify your app and/or reduce # of elements.

You may also want to consider adding this as an option (e.g. add “Enable Accessibility” checkbox in your app option dialog) so Accessibility could be available to users that do need it but provide the perf gains to others who don’t.

Note: in most cases you can simply add an <app.config> file for your .Net 3.5 SP1 app for it to run on .Net 4.
For example: to force app to run in NET 4 add <app.config> file and say :

<?xml version="1.0"?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
</startup>
</configuration>

Or for NET4 Client Profile say:
   <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0, Profile=Client"/>

Comments

  • Anonymous
    December 11, 2010
    .Net 4.0 make the problem less noticeable, but do not solve it completely. WPF apps with some ActiveX(e.g. WebBrowser control with activex content) still run faster without TabTip.exe(e.g. disabled touchscreen drivers)