Jaa

Software Rendering Usage in WPF

  • Artikkeli

As you know by default WPF uses Hardware acceleration (GPU) to render its content (aka Hardware rendering).
In most cases rendering using Hardware (HW) acceleration is much more performant than rendering using Software. In some small cases SW rendering may be faster (E.g. low end graphics card sometimes found in Netbooks).

WPF will always attempt to use HW rendering, but in certain cases WPF will fall to Software rendering and the application may not be aware of it.
Some folks wanted to better understand all the possible cases, so am I am listed these below.
WPF will render in Software when:

  1. Machine video driver date is old (before 11/2004)

  2. WPF detected a "Tier 0" graphic card.
    This means that no graphics hardware acceleration is supported and DirectX version level is less than version 7.0.

  3. The rendered Window's size exceeds the max video card texture size.
    One common scenario for this to happen if you have a WPF window spanning across multiple monitors.

  4. You run your application over Remote Desktop Protocol (e.g. Remote Desktop, Terminal Server, Remote Assistant, etc)
    Until NET 3.5 SP1 and earlier, remoting between Vista to Vista with DWM on, leveraged a custom WPF primitive remoting protocol. In all other scenarios content was remoted as bitmaps. Starting with the release of NET 3.5 SP1 (including NET 4), WPF renders the application content using a software rasterizer on the server and then remotes the content as bitmaps in all cases. Read more here.

  5. Rendering in Virtual Machine.
    WPF will try and render in HW but on some VMs the graphic emulator that comes with the VM is not working correctly. User will have to switch to software to fix the problem. 

  6. The Application is calling the force Software API. E.g.

    RenderOptions.ProcessRenderMode = RenderMode.SoftwareOnly;       // Force Software rendering per Process – New in NET4

    hwndTarget.RenderMode = RenderMode.SoftwareOnly;        // Force Software rendering per Window– Introduced in Net 3.5 SP1

  7. You set the global registry key. E.g.:
    (HKEY_CURRENT_USER\Software\Microsoft\Avalon.Graphics] 
    "DisableHWAcceleration"=dword:00000000 )
    Note: Since this reg key impacts all WPF application consider using this key for testing purposes only.

  8. Application uses legacy style bitmap effects.
    Note: these are obsolete in NET4.

  9. Application printed content.

  10. Rasterized content that uses RenderTargetBitmap

  11. Tiled content that uses TileBrush

  12. Use of too many light objects in your 3D scene. Read more here.

  13. Layered windows (only on XP SP2/W2k3 or before that do not have Hotfix installed.
    See: https://support.microsoft.com/kb/937106/en-us.

  14. Graphics hardware failures, such as "Out Of Video Memory" (OOVM).
    WPF try to free up video memory and stay in HW rendering but it may not always work and WPF will fall to Software  

Which tools can I use to detect if my app renders in Software? The easiest way is to use Perforator which is included with the WPF Performance Profiling Tools and check below check boxes.
Read more here.

Option

Description

Draw software rendering with purple tint

Draws all areas rendered by using the software rendering pipeline with a purple tint. This includes software render targets, software 3D content, and per-primitive software fallback.

Draw software rendered bitmap effects with red tint

Draws legacy software rendered bitmap effects with red tint.

How can I detect if my app renders in Software in code? Check the RenderingCapability.Tier . You can also listen on the Tier change event.

Comments

  • Anonymous
    June 21, 2010
    You mentioned 'Note: these are absolute in NET4.'. Do you mean 'obsolete'?

  • Anonymous
    June 21, 2010
    thnx

  • Anonymous
    June 22, 2010
    I don't know how I missed the option to override the rendering mode on a per-window basis in 3.5 SP1.  Some of our customers experience strange visual artifacting with our WPF applications, so that capability will be very useful.  Thanks!

  • Anonymous
    July 26, 2010
    "In most cases rendering using Hardware (HW) acceleration is much more performant than rendering using Software. In some small cases SW rendering may be faster (E.g. low end graphics card sometimes found in Netbooks)." We have found that SW rendering is noticeably faster on Intel Atom CPUs, which only support rendering Tier 1--this is a HW limitation according to Intel.  Do you know what class of graphics card is needed to get appreciably faster hardware rendering than software rendering?  Would any of the Intel integrated graphics chips (e.g., the latest-gen graphics chip on the Core i3) be faster than SW rendering or do you have to go to a dedicated GPU?

  • Anonymous
    July 27, 2010
    Hi Ben We don’t have a specific list of which  GPUs  are faster in SW.  It depends on the other factors such as bus speed & architecture and your specific scenarios (e.g. you may find the even on your low-end GPU, 3D will be faster in HW). We did hear that some customers complained about the Intel GMA500 performance found in some netbooks. I would still expect that most modern GPUs to perform much better in HW. Your best approach is to test. Also note that there was some small changes to the Rendering Tier definitions in WPF 4. (see: blogs.msdn.com/.../what-s-new-for-performance-in-wpf-in-net-4.aspx) Thank you. Jossef

  • Anonymous
    March 31, 2011
    Hi Jossef, I'm experiencing a problem which seems to be related to your point #14. Maybe you could help me. The context : 2 WPF apps (.NET 3.5 SP1) running on a dual-display XP Embedded machine (DirectX 9.0c) At some point, one of these app freezes. But only the rendering : the GUI stays active (message pump is active, the application is responsive), but the rendering is not done. The freeze can last seconds or forever. The 2nd app keeps running normally. The bug occurs only in a dual-display configuration, the 2nd app being a kind of catalyst (more memory and CPU usage...) Using Perforator, I see that Video Memory Usage is continuously going up & down in spikes (cf : www.hostingpics.net/viewer.php). During that time, one native thread is consuming 100% of a CPU (the stack-trace involves WPFgfx, DirectX, GDI, and video driver) Usually, when the app unfreeze, it's fully software rendered (purple tint with Perforator). Also, de-activating hardware rendering unfreeze the app. My conclusion, so far, is that I'm facing an out of video memory, with an attempt to fallback to software rendering, but there is a loop somewhere trying again in hardware mode. What's your opinion ? Would it be more a WPF problem, or a video driver problem ? or even DirectX ? Are there some parameters I can tune around this ? Thanks for your help.

  • Anonymous
    March 08, 2012
    I'm having problems with a WPF application and adaptive technology software (screen reader such as JAWS & screen magnifiers such as ZoomText). The problem is that these tools don't see any text on the WPF app window. These tools use mirror display drivers & DCM (display chain management) to capture the text that is rendered on the screen. Reading your article, I thought that switching to software rendering (i.e. using GDI) could potentially resolve my problem. I added the related code: hwndTarget.RenderMode = RenderMode.SoftwareOnly; and later tested with WPF Performance Profiling Tool. I got a completely purple tinted window. Unfortunately, this hasn't resolve the problem. Screen readers & magnifiers still can not capture the test written on the screen. Please correct me if my initial conclusion has been wrong.

  • Anonymous
    May 01, 2013
    Kamilimak, I am having the same problem. JAWS 13 is not reading anything beyond the window title and 'Menus', but no menu items. Your post was a long time ago, but just in case.