Since you are using Intel® US15W System Controller Hub, I want to make you aware of a special place to go with your technical questions. The Intel e-Help desk is staffed by Intel representatives dedicated to answering embedded Intel® architecture product, design and development questions for select Intel processors, including Atom and US15W.
The Intel e-Help desk is only available to registered private users. Before you can access e-Help, you will first have to upgrade your community membership to private status. Private account status also allows you to access special documents and tools at the Intel® Embedded Design Center. Note that it usually takes a few days for the approval process, and it normally requires that your company has a Non-Disclosure Agreement (NDA) with Intel. If you are interested, Click here to go to your ‘My Account’ page and request registered private access.
In the meantime, let's see if someone in the community can help you with an answer.
I am using US15W with Windows XP Pro SP3. We have a custom shell that uses WPF. The performance and response time was horrible. Press a button and it would take three seconds for something to happen. The fix for us was to turn down the Hardware Acceleration-- disabled directdraw and direct3d accelerations. Once we set that, our custom shell was very responsive. Day and night difference between the two settings. Anyway, my point here is that the US15W does very poorly with WPF. This may be why you are seeing this.
Note I have tested my WPF shell with IEGD 10.3.1, 10.4 and EMGD 1.5.2. All the same performance issues when Hardware Acceleration is set to full.
Remember this is primarily a LOW POWER part and performance is tuned for that feature.
Tier 1 is appropriate because there are NOT multiple shader engines in the part.
VertexShader 0.0 is appropriate for the IEGD driver as utililization of the hardware vertex engines is not implemented in IEGD 10.1. It is something that is either already supported or will be on EMGD which IS for US15w also. You might want to try EMGD.
WPF is a whole different issue. Microsoft is painfully aware of the issues in WPF and is likely working to get people to stop using it for better stuff they have now.
The issue is that WPF tries to use acceleration even for things where it is inappropriate. Implementing an accelerated call is not totally free. There is overhead involved in setting up the shader logic, handling textures, passing data in and out of the engine, setting up commands, etc. For complex stuff, the time saved by offloading to the graphics engine outweighs the overhead. When you try SIMPLE stuff (the stuff the WPF primarily does) you lose as the overhead outweighs the advantage and things paradoxicly slow down. I have an analogy- consider traveling from NY to CA. If you use plane travel, the overhead (packing, going to the airport, parking, ticketing/luggage handling, security, boarding, etc) is dwarfed by the time saved versus driving a car. Now consider trying to use plane travel to go to the corner store to get milk vs doing it with a car. The overhead would be enormous if you could even find an airport near your store (or not). Lets just say WPF uses a LOT of milk and does not travel coast to coast much.
I am told there is a feature in IEGD that would allow your WPF program to temporarily dial down the acceleration (this feature currently is missing from EMGD). This would allow you to sort of work around the architecture mess in WPF. Take a look at the sample code included in the IEGD release for the IEGDGUI and I believe it should give you an idea of how to access that feature, There may also be a white paper on EDC so take a look here also.
Hope this helps.