Why is WPF ​DropShadow​Effect SO SLOW?

My computer: Intel DX48BT2, Core 2 Quad Q9450 @ 2.66GHz, 8GB DDR3, GeForce 8800 GT, Windows 7 Professional 64-Bit.

Yes it isn't the latest but in fact it runs Crysis pretty well. Yet when I add some DropShadowEffects to ~50 WPF controls, everything gets unbelievably sluggish. Scrolling, resizing, everything is just slow.

What I don't get is how my computer can run Crysis well, but can't draw drop shadows on ~50 controls at acceptable performance. WPF is using the same GPU as Crysis.

So what's going on? Is WPF just this inefficient?

Somewhat related: Even if I remove the drop shadows altogether, the CPU still hovers at ~18% if I just drag a control around inside the app's main window. Once again, how many triangles does Crysis draw per frame, with a large number of shader effects going at the same time...?

by design https://connect.microsoft.com/VisualStudio/feedback/details/530476/dropshadoweffect-to-slow

6 minutes ago, felix9 wrote

by design https://connect.microsoft.com/VisualStudio/feedback/details/530476/dropshadoweffect-to-slow

It's slow by design? More like badly designed/implemented it seems to me.

There is a huge disconnect to what something like a 3D game can do, vs what WPF can do with the same GPU. If you ask the same game developers to design the UI I'm making but using their own techniques, they would probably be able to come up with something that runs rings around what WPF can do. My point is that WPF seems to be hugely inefficient.

BTW, I can't place all of my controls onto one canvas as is suggested in the link you provided because of the way the controls are laid out.

1 hour ago, BitFlipper wrote

*snip*

It's slow by design? More like badly designed/implemented it seems to me.

There is a huge disconnect to what something like a 3D game can do, vs what WPF can do with the same GPU. If you ask the same game developers to design the UI I'm making but using their own techniques, they would probably be able to come up with something that runs rings around what WPF can do. My point is that WPF seems to be hugely inefficient.

BTW, I can't place all of my controls onto one canvas as is suggested in the link you provided because of the way the controls are laid out.

actually i think the "By Design" is not a very good tag for what the MS rep is really saying.

I think the root of this is that if you have a large number of seperate effects to generate it will have in impact. the idea of creating less by using a group is optimising ...

Game developers do that also, they write code to find out what things they can skip in a render pass to help with perf and they find things they can marge and things that can be simplified.

Fun experiment:

• put 50 buttons in a panel, let's say WrapPanel
• set a DropShadow effect on each button, leave the default effect options
• run the app and watch the laggy resizing
• set ProcessRenderMode to software and run the app again. smooth resizing.

So much for GPU rendering

well, the status of that feedback is: "Closed: as By Design"

@figuerres:

All shadows in one pass? what about the shadows overlaping each other, like in this case, 50 shadows overlaping and becomes super dark at intersection.

I suppose that's why they went with Metro. Doing graphics effects like that on large scale is still a challanging for them.

@figuerres:

I am quite familiar with optimizations since I've done quite a bit of 3D game programming (both native Direct 3D as well as XNA) and also realtime audio programming. But that doesn't mean I can apply those types of optimizations to a WPF application. WPF is a high-level API and I don't get access to the low-level stuff. I am at the mercy of how it is implemented. In this case the thing that should be optimized is not my simple application, but WPF.

I could flatten all shadows as felix9's link suggests, and although it improves performance, the resulting effect is wrong since overlapping child controls no longer create shadows on each other. So that is not an acceptable optimization since it alters the final output in an undesirable way.

The bottom line is that WPF is unbelievably inefficient when compared to what can be done for instance in game programming, where both are using the exact same hardware. Yes WPF does a lot of different things, but consider this: If I leave UIElement.Effect at null, the app runs fine, but as soon as I attach a DropShadowEffect to it, the exact same app slows to a crawl, sometimes freezing for 2 seconds at a time (with ~50 drop shadows). How do I optimize that?

@felix9

I think it should be: "Closed: We just designed it so badly and we can't see how we can fix it at this point, so we won't even bother trying". I just don't see how a performance defect can be "By Design". Was it a design goal?

15 hours ago, Dexter wrote

Fun experiment:

• put 50 buttons in a panel, let's say WrapPanel
• set a DropShadow effect on each button, leave the default effect options
• run the app and watch the laggy resizing
• set ProcessRenderMode to software and run the app again. smooth resizing.

So much for GPU rendering

Yea I just tried setting it to software rendering and was surprised to find it was actually faster! I have the latest video driver, and once again I'd like to point out that my computer runs Crysis quite well. There's a joke in there somewhere...

1 hour ago, BitFlipper wrote

*snip*

Yea I just tried setting it to software rendering and was surprised to find it was actually faster! I have the latest video driver, and once again I'd like to point out that my computer runs Crysis quite well. There's a joke in there somewhere...

Maybe GPU computing is just over-rated.

1 hour ago, BitFlipper wrote

*snip*

Yea I just tried setting it to software rendering and was surprised to find it was actually faster! I have the latest video driver, and once again I'd like to point out that my computer runs Crysis quite well. There's a joke in there somewhere...

Does Crysis have many drop shadow effects?

2 hours ago, Bass wrote

*snip*

Does Crysis have many drop shadow effects?

Probably not, but it does contain 85,000 different shaders, and I'm guessing a lot of those are probably more complex than the simple drop shadow effects that WPF struggles with, and a few that are very complex, like the one that calculates shadows for the full scene based on the resulting Z-buffer.

If you read up on what the Crysis engine does, WPF looks like a joke since it can't even do a few dozen drop shadows without becoming unacceptably slow. And Crysis is pretty old by today's standards.

2 hours ago, Bass wrote

*snip*

Does Crysis have many drop shadow effects?

MetroTwit does

Double

I have been using Pixel Shaders to speed up an application that was performing pixel by pixel transformations in code and I now have a very fast application.

The thing is that it's not just the Shader but databinding as well in WPF that can make things slow, which is why we have dependency properties so things filter up or bubble down visual trees (typically static references) for performance reasons.

Why not try building your own pixel shader (or find one on the internet) as you will have complete control of the GPU that way

@vesuvius:

Yea I was thinking along those lines but I guess a lot depends on how WPF presents the surfaces to a custom shader. I have not tried it in WPF so I'm not sure how it works. I would think that with a layered system like a visual tree the shaders would need to be called as each layer has been rendered.

It is possible that the bottleneck is not in the shader itself, but the way that WPF manages those layers. For example, maybe it triggers creating intermediate surfaces if there are shaders involved, which could be where the performance issue is resulting from. In that case there won't be too much I can do to improve things with a custom shader.

But still, it might be worth looking into.

All shadows in one pass? what about the shadows overlaping each other, like in this case, 50 shadows overlaping and becomes super dark at intersection.

I suppose that's why they went with Metro. Doing graphics effects like that on large scale is still a challanging for them.

This is really funny, and sad in a way.

-Josh

8 hours ago, BitFlipper wrote

For example, maybe it triggers creating intermediate surfaces if there are shaders involved, which could be where the performance issue is resulting from. In that case there won't be too much I can do to improve things with a custom shader.

You pretty much nailed it. Setting a DropShadowEffect (and maybe other effects too) on an element causes an additional render target to be created for that element. The element is drawn to that render target and then the contents of the render target are processed by the effect and drawn onto the main render target. This constant switching of render targets likely causes the GPU to stall and that's bad. I wonder why they don't draw the effect elements to their own render targets first and then siwtch to main render target and draw it. This would minimize render target changes.

The pixel shader itself is unlikely to be the problem. In my example if I set the shadow effect on the panel containing the buttons the result is much faster. If the pixel shader was the problem that wouldn't happen, the amount of pixels that require shading is roughly the same.