I can have a lot of controls in my layoutroot (a canvas). And as the tree gets bigger, performance naturally fades and eventually the application becomes unresponsive to most actions.. To give my creep a little push, I am trying to use the GPUAcceleration but I havenT seen any enhancement in the performance and more importantly I couldnT find a way to make sure if it is even trying.
Say I have this set on the Aspx host page of an SL app:
<asp:Silverlight ID="O2PSilverlightXaml" runat="server" Source="O2PSilverlight.xap"
EnableFrameRateCounter="true" MinimumVersion="3.0.40307.0" Width="100%" Height="100%"
EnableGPUAcceleration="true" />
How do i make sure if it worked? How do I know that my graphics card is supported or that it wasnT ignored due to the security settings of the browser ...etc?
This is for Silverlight 4.
From the page you are linking to:
During profiling and performance tuning phases of application
development, you can set EnableCacheVisualization (Silverlight Plug-in
Object) to true to produce an overlay visualization of the areas in
your UI that are being hardware accelerated.
This will give you a visual clue.
Related
We were able to use automation tool and it was able to identify html objects on Winforms while on WPF it does not since it is rendered as an image.
My main question is what does Winform CEFSharp uses to render and why WPF not able to use a similar rendering mechanism?
Warning: it is a very generic answer. I briefly looked at CEF source (briefly - 3-5 minutes) and the rest are my guesses based on my own WPF/WinForms interop experiences. I've had quite a few. I also played a bit with early Chromium builds. However, all of that was a few years ago, so it may simply be out dated. Maybe Chromium has now first-class WPF support. I have not found any information about that, but if this really happened, I encourage you even stronger to follow the last paragraph.
--
I doubt that there is any reason behind this other than time-cost to implement -
either on CEF or Chromium project.
WinForms and WPF are totally different GUI frameworks, written in different eras, using different architectures, different rendering techniques, different platform features, etc. This is as different as it can be, down to the idea of a "Window" itself.
In WinForms, almost every control is a separate small window-like thing, has a system-wide handle, has a system-tracked region, etc. All controls render themselves almost directly by unmanaged win32 GDI+ functions.
In WPF they don't. In WPF there's only one handle per whole window, controls don't render themselves. Instead they have a definition of their "look" and the WPF renders them to the 'surface', which is then blitted/streamed (sorry, dont remember) to target device.
That's true that CEF uses different approaches. For WinForms they make heavy use of a 'browser component' taken directly from Chromium, for WPF they render to bitmap and show/update the bitmap periodically.
Why? My guess is that it's because Chromium already provided a COM/OCX/ActiveX/whatever component, and WinForms can use it almost directly, thanks to the everything-has-a-handle "feature" - if you can call it a feature - one of the goals and successes of WPF was to eliminate that.
However, I don't think that Chromium at that point of time provides any such component for WPF.
If it does not exist, then for WPF there are only two options - one could embed the WinForms component in WPF window through a special 'host' intermediate control, but that actually hits the performance and also has many problems when some advanced rendering features (like movie streaming) are used. Diagnosing and fixing them is complex, hard, and even unstable (crosshosted components behave very differently on different windows and .net versions, even on .net patches sometimes change them, it can work one one, and freeze on other, hang and render as black on next and cause a blue-screen on another)
Other option for WPF is to use the "offscreen" mode. Chromium can render to a bitmap, so why not. Render to bitmap, and display that. Simple. Quick. No problems.
So, I'd say, it all boils down to a famous quote from Eric Lippert:
The question is "why does [snip] not have this feature?" The answer to that question is always the same. Features are unimplemented by default; [snip] does not have that feature because no one designed, implemented and shipped the feature to customers.
It's great we can at least display Chromium in WPF apps. If you think it can be done better and that it's worth doing, it's open source, feel free to implement it - if not in CEF, then in Chromium itself.
I enjoy developing for the web, HTML/CSS/JavaScript are easy to debug and see what is going on with tools built into modern browsers such as Chrome/Firefox and simple things such as view-source
But with WPF, I'm constantly getting into moments where I think something should happen and it just doesn't. I eat up a lot of time in frustration trying to figure out why a damn button is a certain color or text isn't showing up, etc, etc.
How do you make WPF bearable? Am I missing out on any tools? I know I can prototype in tools such as kaxaml but it doesn't always translate into the real thing.
I want an "Inspect element" when doing WPF!
Snoop is the closest thing to Firebug you're likely to get. One thing I can't stress enough though is to watch the Output window while the app is running - it will tell you when styles/brushes/whatever fail to load.
Also, if you're working in a big project and are having issues with a control or style, pull it out to a separate dummy solution and see if the problem persists. XAML isn't as bad as CSS when it comes to weird inheritance issues, but it can really help you see what's going on.
I want an "Inspect element" when doing WPF!
I would recommend trying Mole 2010. It includes a visual inspector for WPF applications.
I have to use self-written WPF application via Remote Desktop with slow Internet connection.
When it comes to scrolling - it looks like application hangs for a second or two. Application runs pretty fast on local computer but when it comes to RDP performance become dissapointment.
I guess I have to simplify WPF render as much as possible. I'd like somehow to tell WPF subsystem: render all of your controls as simple as you can.
What would you suggest here?
There are some tips from the Visual Studio team relating to RDP. This post has a lot of details such as reducing the framerate and implementing VisualScrollableAreaClip. I had a quick look and AvalonEdit doesn't seem to use VisualScrollableAreaClip so that and the other settings mentioned in that post might be worth looking into before retemplating all your controls.
After reading the wikipedia article on WPF architecture, I am a bit confused with the benefits that WPF will offer me. (wikipedia is not a good research reference, but i found it useful). I have some questions
1) WPF uses d3d surfaces to render. However, the scenegraph is rendered into the d3d surface by the media integrated layer, which runs on the CPU. Is this true ?
2) I just found out by asking a question here that bitmaps dont use native resources. Does this mean that if i use alot of images, the MIL will copy each when rendering, rather than storing the bitmaps on the video card as a texture ?
3) The article mentions that WPF uses the painters algorithm which is back to front. Thats painfully slow. Is there any rational why WPF omits using Z-buffering and rendering front to back ? I am guessing its because the simplest way to handle transparency, but it seems weak.
The reason i ask is that i am thinking it wont be wise for me to put hundreds of buttons on a screen even though my colleagues are saying its directx accelerated. I dont quite believe that whole directx accelerated bit about WPF. I used to work on video games and my memory of writing d3d and opengl code tells me to be cautious.
For questions #1 and #3 you might want to check out this section of the SDK that discusses the Visual class and how it's rendering instructions are exchanged between the higher level framework and the media integration layer (MIL). It also discusses why the painters algorithm is used.
For #2, no that is most definitely not the case. The bitmap data will be moved to the hardware and cached there.
I tested that, I wrote two programs that show 1,000 buttons on screen, one in WinForms and one in WPF, both worked just fine.
I then pushed that up to 10,000 buttons, at that point the WPF app took a few seconds to start but run just fine, the WinForms app didn't start.
Win32 itself (and WinForms) isn't built for applications with hundreds of controls (believe me I wrote such an app), at some point it just stops working, WPF on the other hand, keeps working even if it slows down a bit at some point.
So, if you do need to put a lot of controls on screen WPF is your best bet (unless you want to roll your own UI framework - and you think you can do better than the entire MS perf team).
Also, WPF has many advantages other than graphics acceleration: richer graphics, drawing model that is easier to work with, animations, 3d and my personal favorite - amazing data-binding.
This will let you develop richer UIs faster - and I think that will make a much bigger difference than the painting algorithm used.
BTW, if you need to put hundreds of buttons on the screen this is likely to be a bad user experience and you may want to reconsider your UI design,
I love programming with and for Windows Presentation Framework. Mostly I write browser-like apps using WPF and XAML.
But what really annoys me is the slowness of WPF. A simple page with only a few controls loads fast enough, but as soon as a page is a teeny weeny bit more complex, like containing a lot of data entry fields, one or two tab controls, and stuff, it gets painful.
Loading of such a page can take more than one second. Seconds, indeed, especially on not so fast computers (read: the customers computers) it can take ages.
Same with changing values on the page. Everything about the WPF UI is somehow sluggy.
This is so mean! They give me this beautiful framework, but make it so excruciatingly slow so I'll have to apologize to our customers all the time!
My Question:
How do you speed up WPF?
How do you profile bottlenecks?
How do you deal with the slowness?
Since this seems to be an universal problem with WPF, I'm looking for general advice, useful for many situations and problems.
Some other related questions:
What tools do you use for WPF development
Tools to develop WPF or Silverlight applications
How do you speed up WPF?
Often after using one of the following profiling tools it is obvious what is causing my bottlenecks.
If memory is the issue then I virtualize my data.
If render time is the issue then I virtualize the controls or simplify control templates where possible.
If processing time is the issue I try to improve my algorithm or move that work to a background thread and show a throbber in my ui while the work is going.
How do you profile bottlenecks?
.NET Memory Pofiler
dotTrace
Performance Profiling Tools for WPF
Snoop
Crack.NET
How do you deal with the slowness?
Profiling and counseling.
Install SP1... Loads of very cool performance increases for WPF!!!
Read more here
Here is a example of 2 enhanchements made in SP1: Deffered scrolling & UI Element recyceling!!!
I can not add comments, that's why I post a new answer to this: I've found this video from the pdc09 that gives some ideas about how to profile wpf apps and because it helped me lot, I want to share the link:
Advanced WPF Application Performance Tuning and Analysis
WPF is meant for computers with modern graphics cards. Do your clients have modern graphics cards capable of running Aero? If your clients have older graphics cards, WPF will fall back to software rendering which runs extremely slow in comparison to hardware accelerated graphics.
You also might want to profile your application to make sure that it is actually WPF that is the slow part. It's possible that there is something else that is actually the bottleneck.
avoiding animations also helps a lot sometimes. if you have to use animations, decrease the framerate, this will improve "Feeled" performance
Remove alpha transparency/ bitmap effects.
can you give more details?
I only noticed a slow performance when I use something like a listview or a grid that has some complexity. The solution is to simplify it.
Other than that I only noticed a slow performance when loading the app for the first time.
HTH
I find it helpful to side-step the XAML, and write the entire UI in C#. This lets me precisely control when the controls are created and loaded. It also helps me understand what XAML is doing "under the covers".