WPF3D Team Blog : Performance

What's New in Graphics for 4.0 Beta 2

wpf3d — Wed, 21 Oct 2009 01:26:24 GMT

Last beta I mentioned we were saving the best for Beta 2 so thank you for waiting :)

New Features

The PixelShader class now accepts Pixel Shader 3.0 shaders when your hardware supports them. Important: There is no software rendering for PS 3.0. For example, you won't see PS 3.0 Effects over Remote Desktop, when printing, in RenderTargetBitmap, etc...
You can now tell us to cache the render output of an element tree in memory using what we've been calling the "cached composition" feature. The APIs for this feature are UIElement.CacheMode and BitmapCacheBrush. Think of this as hardware RenderTargetBitmap but without the BitmapSource APIs. Cached composition is more efficient than VisualBrush and allows you to specify a scale to render at if you know you'll be zooming. We'll have to write about this more later.
Brand new text rendering and layout. One of the biggest complaints about WPF has been small text "clarity" so we added "Display" mode text rendering which snaps to the pixel grid and looks just like the GDI rendering the rest of Windows uses. Rendering of East Asian fonts that have embedded bitmaps has also improved. All of the details are over at the WPF Text blog. You should be able to notice a big difference over Beta 1 in Visual Studio 2010.
My team didn't do this, but it helps us out quite a bit. WPF layout can position elements on sub-pixel boundaries which causes blurry bitmaps or seams. There have been specific workarounds for these things but no general fix. Now you can set layout rounding on the element tree root and walk away.

Some Notable Bug Fixes

We've fixed most of our D3D9D.dll issues. If you're on XP SP3 you'll still hit a problem that's out of our control. To workaround that or any other issue, you can copy d3d9d.dll to the exe folder, rename it to d3d9.dll, and check the "break on error" box in the control panel as usual but do not enable d3d9d.dll globally. Or you can use the checked D3D9.dll as mentioned in the release notes I just linked to.
Fixed all known D3DImage device lost and timing bugs. If you find more, let us know ASAP.
ColorContext should finally work in all scenarios! It can still throw exceptions when the embedded ColorContext is bad. I believe we shipped Beta 2 with some backwards compat exception issues that have been fixed for final release.
WriteableBitmap was not respecting dirty rect size. If your dirty region is small compared to the size of the entire WriteableBitmap, you will see CPU improvement.
Minor 3D performance improvements. We reduced the amount of DrawPrimitive() calls for large indexed meshes and slightly improved CPU usage for large Model3D counts.
We reduced the amount of GC.Collect(2) calls caused by bitmap allocations
The render thread no longer dies when you create "32 / number of monitors" WPF AppDomains.

A Notable Bug

Remember how I said we disabled hardware rendering if you didn't have PS 2.0? Well, that wasn't true. We thought we did but there was a bug and it's in Beta 2 as well. It'll be true for the final release.

It's also worth mentioning that .NET Framework 4.0 setup size has shrunk dramatically. The full x86 installer is down to ~38MB and the new "client" installer down to ~31MB. Full 3.5 SP1 is 231MB!

-- Jordan

Transparent DiffuseMaterials and Depth Sorting

wpf3d — Fri, 19 Jun 2009 04:28:00 GMT

I hinted at this a long time ago and then forgot to follow up, whoops!

As the old post says, DiffuseMaterial writes to the depth buffer. This means if you draw one diffuse model and then draw another diffuse model behind it, the card knows not to draw the second one on top of the first because the first is closer. The depth buffer only knows about position and has no concept of transparency so if the first model is transparent, you won’t see the second model behind it because the depth buffer rejected it as being behind the first.

What does this mean? This means you have to sort your transparent DiffuseMaterials from back to front. If your scene is dynamic, you’ll have to do this any time the relationship between the transparent models and the camera changes. Peter gives an example of how to do this here.

-- Jordan

P.S. If you have a lot of overlapping models (a.k.a overdraw) you can sort your opaque models from front to back. This will prevent all of the obstructed models from being rasterized and will improve performance if rasterization is the bottleneck. If you have both opaque and transparent models, first draw the opaque ones then the transparent ones.

3.5 SP1 Software 3D Leak Fix Available

wpf3d — Tue, 09 Jun 2009 01:34:00 GMT

In 3.5 SP1 it was really easy to leak memory when doing software 3D rendering involving a VisualBrush or DrawingBrush. We got this complaint many times online and in person. Unfortunately, there is no work around. It’s described in “Issue 2” from this new Knowledge Base article. The fix should also be in 4.0 Beta 1.

-- Jordan

3D Hit Testing

wpf3d — Tue, 19 May 2009 04:22:00 GMT

How to do 3D hit testing has come up a bit recently in the forums but essentially it isn’t any different than 2D hit testing which is described on MSDN here. You can either start with a 2D point on the Viewport3D or a 3D point on a Visual3D.

Starting at the Viewport3D level is straightforward. Suppose you have a mouse down handler and you want it to hit test into 3D:

public void MouseHitTest(object sender, MouseButtonEventArgs args)
{
    Point mousePos = args.GetPosition(viewport3d);
    PointHitTestParameters hitParams = new PointHitTestParameters(mousePos);
    VisualTreeHelper.HitTest(viewport3d, null, ResultCallback, hitParams);
}

Visual3D is slightly trickier because a point is no longer sufficient in 3D space. You also need to specify a direction. An origin point plus a direction is known as a ray. It will look something like this:

    RayHitTestParameters hitParams = 
        new RayHitTestParameters(
            new Point3D(0, 0, 0),
            new Vector3D(1, 0, 0)
            );
    VisualTreeHelper.HitTest(visual3d, null, ResultCallback, hitParams);

The only difference is the HitTestParameters.

The second argument to HitTest is a filter which allows you to control which parts of the tree get tested. Skipping part of the tree is a perf win of course, but generally you’ll want to hit test everything and this is covered well in the MSDN article so I won’t do it here.

The third argument, the result callback, is where the action happens. We’ve hit something and we’ve decided to tell you about it. It could be 3D or it could be 2D. It’s up to you to decide what you’re looking for and when/if you want to stop.

public HitTestResultBehavior ResultCallback(HitTestResult result)
{
    // Did we hit 3D?
    RayHitTestResult rayResult = result as RayHitTestResult; 
    if (rayResult != null) 
    { 
        // Did we hit a MeshGeometry3D?
        RayMeshGeometry3DHitTestResult rayMeshResult = 
            rayResult as RayMeshGeometry3DHitTestResult;
                                                                                          
        if (rayMeshResult != null) 
        { 
            // Yes we did!
        } 
    } 
    
    return HitTestResultBehavior.Continue; 
}

RayMeshGeometry3DHitTestResult has MeshHit, PointHit, and DistanceToRayOrigin properties which tell you pretty much everything you want to know. It also has the triangle indices and weights (a.k.a. barycentric coordinates) so you can do things like figure out the texture coordinate of the point hit.

Performance Tip: As you mouse over 3D we do hit testing behind your back because there could be interactive 2D on the 3D or a 2D layer underneath the 3D (empty Viewport3D space is considered transparent for hit testing purposes). If you know you don’t need either of those, disable hit testing on the Viewport3D by setting its IsHitTestVisible property to false. This is an old tip but a good one :)

Sneaky Performance Tip: Can’t disable hit testing and it’s still eating up a bunch of CPU? Override HitTestCore() and, while the mouse is moving, only really issue the hit test every two or three (or more!) requests. This will introduce lag of course but that may be acceptable to your application.

-- Jordan

Bootcamp Lecture

wpf3d — Thu, 29 Mar 2007 21:34:00 GMT

We gave a lecture on 3D yesterday at a "WPF Bootcamp" event and I've attached the slides. Here's the outline:

Intro to WPF3D with a simple example
Interactive 2D on 3D
Performance tips (based on this paper)

-- Jordan

WPF3D Perf Guide for Tier 2 Hardware

wpf3d — Wed, 17 Jan 2007 02:45:00 GMT

David Teitlebaum has put together a set of perf guidelines which should help you get the most out of WPF3D on Tier 2 devices.

<Disclaimer> Before you go off and implement all of the tips be sure to profile your application to find out where the true bottlenecks are in order to get the most improvement for the least amount of effort. Furthermore, these are just guidelines that are generally true but in reality they may differ depending on the underlying hardware </Disclaimer> :)

In the future, we hope to expand upon some of the tips here on the blog.

-- Jordan