Vista - WPF: making simple things easy and difficult things impossible? (Rant)

Hi everybody.

I have been playing around with WPF for the last few months. I have
been working with the excellent book "WPF unleashed" by adam nathan.

So far I must say that WPF is a beautifully designed API that finally
enforces a good separation between content and presentation.

But as soon as you try to do something more complex, especially with
complex animated geometry, the whole thing slows to a crawl. The thing
I am interested in is scientific visualization, namely real time
graphs of satellite telemetry.

I am using hardware that I would consider quite modern: a 2GHz Core
Duo notebook with a DirectX9 compatible intel graphics card (HP
TC4400) and an Athlon XP 2500+ with an directx9 compatible nVidia
graphics card. But whatever I do, I can not even get decent frame
rates for a simple particle system with a few thousand particles. I
tried several approaches (one big DrawingVisual, one DrawingVisual per
particle, writing a custom animation, subscribing to
CompositionTarget.Render, etc.).

Both graphics cards are fast enough to play FarCry in full resolution,
so please don't tell me that I should just get a better graphics card.
And by the way, I am quite sure that the bottleneck is not the
graphics card but the scene graph management, which is of course CPU
bound.

As I see it, my options are the following:

a) live with the crappy performance (then I might as well stay with
System.Drawing)

b) Implement my own 2d vector graphics API on top of DirectX (That is
a huge task. I have no time for that)

c) hope that microsoft will improve the performance: that is pretty
unlikely since microsoft does no longer seem to care about performance
at all. They have not even solved this very fundamental .NET
performance issue: http://connect.microsoft.com/VisualS...edbackID=93858.

And the performance of the newer APIs is consistently slower than the
older apis. Raw geometry rendering performance in WPF is slower than
GDI+, which is slower than GDI (I know that WPF is quite fast in
compositing multiple semi-transparent video streams, but I am not
interested in that).

d) Switch APIs. Building my own 2D api on top of OpenGL would be
significantly easier than building it on top of DirectX, since there
are some very helpful things like a concave polygon tesselator in
GLUT.

As you can imagine, none of the above options are very appealing to
me. And I am not the only person having performance problems with
WPF.

Microsoft should really expose the immediate mode 2D vector graphics
API that is used by WPF internally to tesselate geometry. This could
be done by just having an ImmediateDrawingContext inheriting from
DrawingContext that creates a list of triangles and shaders instead of
creating a display list. This would not even require much additional
coding, since obviously the tesselator that creates a list of
triangles and shaders from WPF data structures already exists.

Our company can not currently use WPF anyway since many of our
customers are using Windows 2000. But if the next version of WPF does
not contain any way to render complex geometry with decent
performance, we
will have to switch to using OpenGL.

Microsoft should really think hard about their new approach. Sure, WPF
is a beautifully designed API. But the reason Win32 was so successful
was not that it was beautiful, but that it was fast and gave low
overhead access to the underlying OS capabilities. A crufty api like
Win32 that lets me do what I need with low overhead is far preferable
to a beautifully designed API that does not give me access to the
hardware capabilities.

cheers

Rüdiger Klaehn

WPF is designed for UI, not for large-scaled information
visualization, in which OpenGL is my first choice. Regarding DirectX,
the managed code should be slow. You may consider separate UI with WPF
from visualization (using OpenGL). BTW, there is a C# wrapper of
OpenGL open source, but not sure the performance.

Let's make something clear. If there are no animations, WPF can have lots of
particles...thousands...whatever...

If you need reasonable frame rate for animations like around 30 FPS, then
WPF can generally handle less than 500 on a really good system.

So, the problem here is the animation of thousands of particles, not the
rendering of a single scene with thousands of particles.

The solution is to either design the visualization to match the performance
of the end machine in WPF, or go with another lower level api to get more
power.

I'd recommend looking into XNA as it is the managed version of DX for indy
games for Vista and XBox, and it will handle what you want and there is
shader support, HDR support and etc...which WPF doesn't have.

Flash can't animate thousands of particles either at 30 FPS unless it's a
movie



"Frank Wu" wrote:

> WPF is designed for UI, not for large-scaled information
> visualization, in which OpenGL is my first choice. Regarding DirectX,
> the managed code should be slow. You may consider separate UI with WPF
> from visualization (using OpenGL). BTW, there is a C# wrapper of
> OpenGL open source, but not sure the performance.
>
>

I want to mention another option which is to have a HUD which allows the user
to move around, but without animations taking place which require high frame
rate.

For example, there are many 3D Cad meshes out there and they are very
complicated. The compromise of looking at the mesh from 30 degrees and 60
degrees and 120 degrees around different axis points doesn't require
animation...it would be nice...but if the FPS is not there, then fade out the
current render image, calculate the next render image, and perhaps crossfade
the new image into view.

This technique will allow the user to view from many different angles a very
complex visualization without the need for 30 Frames per second. It's
essentially, a bunch of still frames which are dynamically created on the fly
depending on how the user wants to interact with the object.

I will also add that WPF interop's well. So, a DX app will run within a WPF
app. You will not get overlay composition, but it a good way to take
advantage of the quick dev time WPF offers.


"TheRHogue" wrote:

> Let's make something clear. If there are no animations, WPF can have lots of
> particles...thousands...whatever...
>
> If you need reasonable frame rate for animations like around 30 FPS, then
> WPF can generally handle less than 500 on a really good system.
>
> So, the problem here is the animation of thousands of particles, not the
> rendering of a single scene with thousands of particles.
>
> The solution is to either design the visualization to match the performance
> of the end machine in WPF, or go with another lower level api to get more
> power.
>
> I'd recommend looking into XNA as it is the managed version of DX for indy
> games for Vista and XBox, and it will handle what you want and there is
> shader support, HDR support and etc...which WPF doesn't have.
>
> Flash can't animate thousands of particles either at 30 FPS unless it's a
> movie
>
>
>
> "Frank Wu" wrote:
>
> > WPF is designed for UI, not for large-scaled information
> > visualization, in which OpenGL is my first choice. Regarding DirectX,
> > the managed code should be slow. You may consider separate UI with WPF
> > from visualization (using OpenGL). BTW, there is a C# wrapper of
> > OpenGL open source, but not sure the performance.
> >
> >