In WinForms you could set a progress bar to loop endlessly to indicate that you don't know how long it will take. How would I do that in WPF?
<ProgressBar IsIndeterminate="True" />
I personally like the approach Visual Studio 2010 takes. They use an animation of a small, looping series of dots (with varying intensity). They just animate the dots circling in the center of the window in question.
In WPF, this is trivial - just animate a rotation of a small drawing of a circle of dots with the opacity set correctly up front.
I find it very intuitive, small, and unintrusive.
Is a progress bar the right widget for this? You are unable to indicate a % complete, since you "don't know how long it will take". Maybe an animation of some sort (like the Windows files-disappearing-into-thin-air-while-deleting effect) to show that activity is still going on would be better. But a "progress" bar that simply resets to zero because there is still more work to do just looks dumb to me.
Related
Other questions on SE address how to speed up nested UI control resizing, but- what if there aren't any controls?
As you drag the edge of a WPF window, even a main window with no content, black bars flicker briefly during the drag. This produces a crummy feel- one that I don't want to inflict on customers:
It does get slower and heavier with a full UI on top of it as well. This doesn't even get into how ugly it looks when resizing using the top or left edges. Windows Forms- even with the heaviest UI I've built- never looks this bad right off the bat.
What can be done to make WPF window resizing performance comparable to win forms?
(I have Windows 7 x64 and a triple monitor system on an AT Radeon HD 7470.)
You could update your graphic card and try it out again but that wont change anything. The reason is pretty simple. We all get to see this sometimes based how fast/slow our computer is. Sometimes it runs smooth because we do not have many visuals to draw. The reason is no proper background color is found in graphic card at that moment in redrawing process. Your drivers are fine, and its not just because you use Wpf. Other techniques use the same mechanism behind redrawing.
The first thing WPF will do is clear out the dirty region that is going to redraw. The purpose of dirty regions is to reduce the amount of pixels sent to the output merger stage of the GPU pipeline. Here is where we see the black color. Window itself at that point has no background color or its background color is set to transparent and so to us the GPU draws the black background. Things run async in wpf which is good so.
To fix this you could set a fix color such as "White" to the Window. Then the WPF system will clean out the dirty region but fill it automatically with white color instead of black. This usually helps.
Match the window color or the color of top most layer. Dont let GPU use black and you should do fine. Btw Wpf is faster than WinForm so dont worry.
The look is crummy indeed, especially when using the top or left border.
Which exact problem your screen shot is showing depends on how long your app is taking to render as well as a couple of background related settings that you might be able to tweak to get better resize. Plus part of the ugly resize is specific to Aero.
While I can't address the specific crazy slowness of WPF redraw, I can at least give some insight on why you see black, where that is coming from, and whether you can change to a less annoying fill-in color.
It turns out there are multiple different sources of the black and the bad resize behavior from different Windows versions that combine together. Please see this Q&A which explains what is going on and provides advice for what to do (again, not specific to making WPF faster but just seeing what you can do given the speed you have):
How to smooth ugly jitter/flicker/jumping when resizing windows, especially dragging left/top border (Win 7-10; bg, bitblt and DWM)?
I have a WPF window that contains a fancy image with roughly 200 controls (derived from buttons), all of which use one of my 5 templates (paths, shadow effects, etc). Agreed, it is a heavy window to draw. I can live with that.
My problem comes from resizing the window. Maximize/Restore take about 1-2 seconds, but manually dragging the bottom-left corner causes the system to hang for about 5-10 seconds. In that delay, the window is black & contains partial leftovers until the final result is shown. It looks amateurish and that, I can't live with.
Remote connection : using a remote account, I found that the window resize always takes 1-2 seconds, but doesn't draw the "intermediate" stages while I'm dragging the window borders. The result is as snappy as I would expect.
My conclusion is this: It's the redraws during the resize that are bottlenecks.
The inevitable question is this : how can I prevent redrawing the window until the resize is finished?
Thanks in advance for any ideas...
#Seb: I'm beginning to think WPF is
not designed for interfaces that go
beyond 2-3 controls at a time
Visual Studio 2010 and Expression Blend should be good counterexamples. Though Visual Studio sometimes freezes the bottleneck is definitely not in the WPF rendering.
#Seb: The inevitable question is this : how
can I prevent redrawing the window
until the resize is finished?
Simply set the window's content visibility to Visibility.Collapsed before the resize/maximize and make it visible afterwards. Though I think you asked the wrong question. Here is the right one
How to make my controls measure/arrange extremely fast?
And to answer it you should take a look at your code. Maybe you intensively use dependency properties in the measuring/arrange algorithm? Or maybe you picked wrong panels (e.g. Grid is slower than Canvas)? Or maybe... I stop guessing here :).
By the way, it's always better to launch your app under profiler and prove the bottleneck rather than assuming the place where it might be. Check Eqatec Profiler it's free yet powerful enough. VS 2010 also offers nice profiling features, though it's far from being free. And you may want to check WPF Performance Suite.
Hope this helps.
Let me know how this works... I am assuming that your root visual item is stretching to horizontally and vertically to fill your window with auto height/width. Get rid of the Auto height/width. On app start up set the dimensions of the root element. There is a FrameworkElements have a size changed event. Register for this on your Application.Current.MainWindow (maybe be a typo, that was from memory). Whenever this event fires, start a timer with a small interval. If you get another resize while the timer is running, ignore it and reset the timer. Once the timer fires, you now know the new size the user desires and that they have (at least for a short period) stopped resizing the window.
Hope that helps!
From Ragepotato's answer and your comment about needing to see roughly what the interface would look like while resizing, as long as you don't have your objects dynamically re-locating themselves (like a Wrap Panel) - you could take a screenshot of the window contents and fill your frame with it.
Set it to stretch both height and width, and you'd get a (slightly fuzzy) idea of what a particular size would be. It wouldn't be live while resizing, but for those few seconds that probably wouldn't matter..
I am new to WPF in general and want to add some animation to my interface.
I have a label and an image. The label will fly in from the right side of the window, the image from the left. They'll meet in the center. The image will rotate while its flying in, while the text will pretty much just move across the screen.
So my question is. For this kind of animation do you get a path object where you can draw a line at design time and have elements move across this line at a certain speed?
In classic windows forms I would have approached the issue using a timer and then adjust the left property of the label at each tick. Surely WPF is more sophisticated than this though.
So can anyone tell me a good approach?
First: You need ExpressionBlend to create animation in WPF.
WPF is more sophisticated
Of course no, read about animation in WPF, Personally, I prefer video learning for it.
you can find here some clips, I recommend this series from Total training.
I have an app with a bunch of controls in it and I want to place a set of cross hairs on top of it. My first attack used a PictureBox and ran into this problem. The solution that fellow proposes, seems a bit... verbose for what I need.
Is there a simple way draw on top of my form? Note that I don't even need the drawing to be part of a control as it doesn't need to do anything but just be there.
This eventually worked. I had to play some games though because most of the controls I wanted to draw on were not where it expected them to be.
Also, it ran into issues when controls were moved; it failed to redraw and stuff moved with the underlying control. This was fixed by forcing invalidation from the move event for anything that might move.
Does a PictureBox with a transparent image have the same problem as a Panel with BackColor set to Transparent? I'm thinking you could have a PictureBox with the crosshair image in it and move that around, instead of drawing it yourself...
I'm using DwmExtendFrameIntoClientArea in my WPF application to get the glass effect. This is working fine. What I'd like to do is change the colour used for the glass -- I'm writing a countdown timer, and I'd like the window to be the normal glass colour most of the time, and then to go red (but still with glass) when the time runs out.
I found this question, which talks about how to apply a gradient glass, and that works fine when picking a different colour. Unfortunately, the borders are not coloured appropriately.
When I turn off the borders by using ResizeMode="NoResize", then I end up with square corners. I'd like to keep the rounded corners.
I looked at creating an irregularly-shaped window, by using AllowTransparency="True" and that works fine, but doesn't look like an Aero glass window. It looks a bit flat.
So: my question: how do I create a window in WPF that looks like Aero glass transparency, but uses a different colour?
I think the only possible way to achieve this is to use a semi-transparent filled border and draw it over the entire window or the part you got the glass. Its a workaround but I guess it's a possible solution since the color of the glass gets defined by the system-user and this setting would overwrite yours.
I'm asking the same question myself.
I haven't found a good solution, though the best I've come across so far is doing the following:
HwndSource.FromHwnd(hwnd).CompositionTarget.BackgroundColor = Colors.FromArgb(100,255,0,0);
Unfortunately this tints the minimize, resize and close buttons, which I would rather avoid.