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)?
Related
I have a WPF application showing a large image (1024x1024) inside a ZoomableCanvas. On top of the image, I have some 400 ellipses. I'm handling touch events by setting IsManipulationEnabled="True" and handling the ManipulationDelta event. This works perfectly when zooming slowly. But as soon as I start zooming quickly, there is a sudden frame-rate drop resulting in a very jumpy zoom. I can hear the CPU fan speeding up when this occurs. Here are some screenshots from the WPF Performance Suite at the time when the frame-rate drops:
Perforator
Visual Profiler
Software renderer kicks in?
I'm not sure how to interpret these values, but I would guess that the graphics driver is overwhelmed by the amount of graphics to render, causing the CPU to take over some of the job. When zooming using touch, the scale changes by small fractions. Maye this has something to do with it?
So far, I have tried a number of optimization tricks, but none seem to work. The only thing that seems to work is to lower the number of ellipses to around 100. That gives acceptable performance.
Certainly this is a common problem for zoomable applications. What can I do to avoid this sudden frame-rate drop?
UPDATE
I discovered that e.DeltaManipulation.Scale.X is set to 3.0.. in the ManipulationDelta event. Usually, it is around 1.01... Why this sudden jump?
UPDATE 2
This problem is definitely linked to multi-touch. As soon as I use more than one finger, there is a huge performance hit. My guess is that the touch events flood the message queue. See this and this report at Microsoft Connect. It seems the sequence Touch event -> Update bound value -> Render yields this performance problem. Obviously, this is a common problem and a solution is nowhere to be found.
WPF gurus out there, can you please show how to write a high performance multi-touch WPF application!
Well I think you've just reached the limits of WPF. The problem with WPF is that it tesselates (on CPU) vertex grafics each time it is rendered. Probably to reduce video memory usage. So you can imagine what happens when you place 600 ellipses.
If the ellipses are not resized then you could try to use BitmapCache option. In this way ellipses will be randered just once in the begining and then will be stored as textures. This will increase memory usage but should be ok I think.
If your ellipses are resized then previous technic won't work as each ellips will be rerendered when resized and and it will be even slower as this will rewrite textures (HW IRTs in perforator).
Another possibility is to design special control that will use RenderTargetBitmap to render ellipses to bitmaps and then will render it through Image control. In this way you can control when to render ellipses you could even render them in parralel threads (don't forget about STA). For example you can update ellipse bitmaps only when user interaction ends.
You can read this article about WPF rendering. I don't agree with the author who compares WPF with iOS and Android (both use mainly bitmaps compared to WPF). But it gives a good explanation about how WPF performs rendering.
I am trying to remove the border of my WPF window in the design view/tab in Visual Studio. Please don't mistake this as a request to create a border less WPF window. I did that and it is working fine. What bothers me is that even if you have set WindowStyle = None, ResizeMode = NoResize, the design view/tab still shows a border around your window in the preview.
Is there a way to remove said border and have a 1:1 preview of the border less window as in Windows Forms?
Every question I have found in regards to this only asks how to remove the border of the actual application. I would like to remove it in the preview.
Any help would be very much appreciated :)
here is a screenshot of my problem:
This cannot be done as this is just how Visual Studio renders a window in design view (I think the frame is probably there so that you can distinguish when you are editing a Window rather than a UserControl).
Rather than try and find a solution to this I would ask myself if this is something I need to be spending time figuring out - after all you say that your program works correctly when being run. I think your time will be better spent writing code for your program rather than trying to play with the design time environment.
Update: In response to you comment, consider that the window frame will be different on every users machine depending on their operating system version (XP vs. Win7) or the theme the user has installed.
My computer has XP installed so the side borders are a lot thinner than those shown in design time so any content will be smaller (but only my a few pixels - 4 in my case; does your user interface design really depend on 4 pixels?).
When using a technology such as WPF you should not be designing your UI to fit to exact pixel sizes; you should be designing with min / max values or using layout containers that adjust to the size of the window as set by the user. Any regions in your UI (E.G. sidebar and main content) should be expressed as a ratio or percentage of one another; instead of saying "The side bar is 150 pixels wide and the main content area is 350 pixels wide" you should be saying "The side bar takes up a third of the window width and the main content takes two thirds".
Although the question is very old and have already been answered (kind of), I just realized: if you set WindowStyle="None", your undesired border is gone.
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..
Given a WPF Application running full screen, a fair amount of controls some of which will animate from off screen to center. I was wondering if there are any special ways to save on the amount of time required to optimize an application for different screen resolutions?
For example, using Blend I've setup some text, which is originally off screen to scroll into view. Now in design mode the start positions are static. If resolution changes the start positions will obviously not be correct.
So I guess to correct this, during app startup. I need to
Check resolution
Move the text box to the desired start location
Adjust the storyboard as required, so the frames all have correct co-ordinates depending on the res of the screen.
I don't mind doing all of this, but if there is an easier way please share!
Thanks
In WPF layout of controls should be made in such way, that when size of window or content changes, controls automaticaly resize/reposition themselves to reflect this change.
This is highly affected how your layout is made, especialy by using specific panels, that do layout of their child elements.
This is also made obvious by using device-independent units for sizes, margins and sometimes positions of controls. And also allows different kind of zooming and scaling of whole UI without any need to redesign the whole thing.
If you are trying to position your controls absolutely, either by using Canvas panel or margins, your are doing it totaly wrong.
In WPF, scene is measured in abstract units, not pixels, and controls are freely scaled. There should be no problems to center something, or what?
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.