THis might be a very vague questions and apologies if posted in the wrong forum.
But I am starting out on a project involving C# and WPF. This project requires some really serious heavy graphics, want the final result to be as smooth as an iPad graphics. So, now my question is, is WPF upto the task? if not can I do something about it? Hardware boost? or if not is there anyway to leverage on Direct X? or third party libraries?
As everything reagarding to 2D graphics in WPF is based on DirectX calls, you will probably not find any faster way except using DirectX directly.
To my understanding everything regarding graphics on an IPad/IPhone seems faster compared to other devices is based on the fact that the rendering on those devices is done in a dedicated thread.
As long as you are not going to use Windows Forms (where everything is rendered using the CPU) you should be fine ;-)
Related
I know this type of question has been asked a lot, but I really can't find something that nails what I'm looking for, so hopefully this is not considered an "asked without research"-question.
The backstory: I'm developing an app that initially was supposed to work on OSX/iOS, but having a Windows version is already a must. I'm trying to find out the easiest way for me to have to translate as little as possible between each version, and preferrably without having to learn too much new (I have a little time constraint).
I'm using C#, currently developing in Mono
I'm used to the Cocoa API on iPhone using MonoTouch
So, my options (as I see them now):
Go native on mac, meaning having to make a separate graphics routines for the other OSes - makes the mac version easy-peasy, and I could postpone any learning curve for the other ports, however I guess it requires a lot more meddling when porting
Use some kind of XML markup or HTML/JavaScript as a presentation layer, with hooks on links triggering backend events (I don't know how well that would work on different platforms) - would require me to learn a bit of JQuery, but it seems pretty straightforward
Make it an XNA project and use MonoXNA (or similar) to port - would require me to learn enough XNA to do it, don't know if it's a pain
Use some other multiplatform 2D kit I don't know of
Basically, I need animated 2D sprites, mouse and touch input, and it would really be nice to have movement keyframes and maybe rotation.
There's also sound, of course, but playing a sound file seems so simple on all platforms that writing platform-specific shouldn't be much hassle.
Have a look at MonoGame. It should suit your needs pretty well I think.
can anyone suggest any alternative to GDI?
The reason is that I have data that updates rapidly and GDI doesn't support that kind of render velocity... I've tried SharpDX & SlimDX, but none seems to work properly (can't force them to draw on form without errors)
Update 1: I'm developing in C#
Update 2: Data is binded to Visual Studio 2010 default Charts control. A lot of code has been written to add functionality & lags were discovered after large amount of data incoming. Reason is that I need compatibility with .NET Framework 4 & Windows XP and higher.
After spending a lot of time investigating, I've discovered that SlimDX and SharpDX have strict requirements to videocard, drivers, and problems running on Windows XP.
GDI is software only rendering, as well as GDI+ which handles alpha channel for transparency rendering. These two libraries are really limited and slow compared to a GPU based one.
My suggestion is that you should invest the time to implement a SharpDX Direct2D based drawing engine. I never heard about the issue you talked about with forms, I use SharpDX with Winforms and WPF and everything's going great!
If speed is the most important criteria, then you'll have to invest time into a GPU based rendering engine, GDI is way to slow and not adapted to real-time rendering.
Honestly I find it strange that GDI doesn't suffice in that context but there are a lot of alternatives: you could go for DirectDraw for complete power, GDI+ for more advanced manipulations and options, or even external softwares like GTK+.
I'm currently working at a application that helps people understand how to do there job. You can see it as a personal coach that guides them trough all the steps they need to do that no normal person could keep remembering.
In my previous application we had the ability to show the user up to 4 pictures (what proves to be more then enough). The application would load the data and see how many pictures where in every instruction and then sort out the picture in the best fitting way without messing up the scale and resolution of the pictures. This all was done with GDI+ and worked very well.
Ofc, change is something that always happens, my bosses came up with some great ideas. So they want to be able to see movies on the screen, animated gif's, 3D models that can rotate or animate. So I think we had pushed GDI+ to it's limits and it's time to look for something different.
I have heard and readed about WPF but have no experience with it. Is it even possible to do all what I ask in WPF? And what about the old picture-merging thing I wrote, can we also get it done in wpf? I tried to make some things working but I didn't went as smooth as I hoped.
I'm also concerned about the fact that the interface needs to be dynamic, the one moment it should be showing picture with some text above it, the other moment it should be showing another text with a video under it.
I would love to hear some opinions here and if you got some other suggestions I should look into pls tell me. Thnx in advance
PS: If WPF is the choice, should I convince my boss to change to .net 4.0?
Although my answer can be termed subjective, I find WPF better than GDI+ anyday. You can do everything you can in WPF which you have done/could do in GDI+ (apart from pure games/game engines). If you can afford the steep learning curve of WPF, I think it will be better investment as this technology is not going anywhere soon.
As for .Net 4.0, WPF 4.0 does introduces some important functions in 4.0 (specially easing functions for animations) but there is nothing you cannot do without if you are using 3.5. I won't recommend 3.0 though mainly because of performance in animations.
WPF is up to the task, but you could also check other options.
You could go web based, and have either an XBAP (WPF in the browser), or Silverlight/Flash app.
Silverlight/Flash doesn't require that much from the client (to install), and is easily updatable, and both can do the job.
I know WPF is more complex an flexible so could be thought to do more calculations. But since the rendering is done on the GPU, wouldn't it be faster than Winforms for the same application (functionally and visually)?
I mean when you are not running any games or heavy 3d rendering, the GPU isn't doing heavy work, right? Whereas the CPU is always busy.
Is this a valid assumption or is the GPU utilization of WPF a very minor operation in its pipeline?
EDIT: The application that I am interested is a 3d modeling and animation software, where you have 3d viewports to navigate and edit the scene, and objects inside the scene. But I want to use WPF because of its modern architecture, and it's from scratch.
EDIT2: Also for my purposes I will use DirectX hands down for the app itself because of the high end requirements of the software. As for people using lower end or computers without a dedicated GPU, that's OK since they aren't not in my primary customer area. Just like other high end 3d software for film and games, it will be understandable to require a powerful computer to fully benefit from the application.
Provided the machine has a GPU, you'll get better rendering performance in WPF.
We have a large desktop application that we wrote in WinForms, and are now porting to WPF. We've witnessed much better rendering performance, particularly when resizing windows or redrawing controls.
We've also found that WPF "controls" are more lightweight than WinForm controls. If I recall right, WPF controls do not necessarily require an operating system handle, and don't register for Windows window messages via WndProc, at least not independently.
For your case, since you're building a 3d modeling app, which kind of assumes some 3d hardware on the machine, you should absolutely use WPF over WinForms.
For the app scenario you describe, I would expect WPF to outperform WinForms for 3D work on a full featured GPU by a wide margin.
The difference between the application types is more than just the rendering the 3D vector pipeline. WPF's internal architecture is radically different than WinForms, specifically designed to overcome the caveats learned from years of prior experience with the Windows GDI and WinForms apps.
(WinForms is a relatively thin wrapper around Windows GDI and User model that was originally created in the late 1980's. The Windows User control model has evolved over the past 25 years, but the core architectural patterns are largely unchanged.)
For example, WPF always separates UI rendering from application logic. When the WPF window goes to draw something, the actual rendering happens on a background thread. The refreshed visuals are flipped to the display during the video retrace interval, so you don't get partial blits or "tearing" artifacts on screen.
WinForms does none of this. If you render to DirectX or OpenGL surfaces in a WinForms app, you have to do the work of flipping the video page and making sure it happens at the right time to avoid screen tearing artifacts.
Wpf's default controls are GPU aware and can be custom styled with glows and transparency and whatnot all GPU accelerated. WinForms controls do not benefit significantly from GPU features, since about the only things WinForms (Windows User controls) uses for rendering are 2D bitblit and rectangle fill. Glows, transparency, animations are all possible with WinForms, but you have to do all the work to implement them.
In WPF, UI slickness is mostly a matter of designing and styling to get WPF to do it for you. In WinForms, you have to push the pixels yourself.
This is a really tough question to answer.
A huge portion of WPF performance is your GPU. A good GPU works wonders for making WPF perform well. WPF can be very performant. If your requirements are to have a decent GPU, since it's a 3D modeling program, you'll probably find WPF performance to be as good or better than Windows Forms - though this really depends on what you're using.
That being said, it's usually difficult to compare - mostly because WPF allows you to add a lot of visual effects that people tend to never even attempt in Windows Forms. Many WPF applications "seem" faster even though they're actually slower in some instances because of extra visual clues.
That being said, if you have a LOT of controls, WPF can actually outperform Windows Forms by a fair amount. In Windows Forms, each control requires a separate window handle, and receives its own message sets. With a lot of controls, this can actually slow things down pretty dramatically.
The real question here should be is WPF perf. "good enough" for your application. If you're doing a 3D modeling application, chances are WPF will not be your bottleneck- it should be fine.
For 3D modeling, WPF is clearly a lot better choice than WinForms -- but it's still a long ways from ideal. Winforms has no (direct) support for 3D rendering at all, and WPF has some. For a program that's aimed primarily toward 3D rendering, however, you might be better off with something dedicated more specifically to 3D rendering tasks, such as OpenGL or Direct3D.
On their own, neither of those provides a huge advantage over WPF, but unless what you're doing is fairly specialized, I wouldn't use those directly though. I'd use something like OpenSceneGraph or Ogre3D, that can use either of those for its rendering, but provides a much higher-level interface and does more to manage rendering your scene.
Either or both of these probably could use WPF for the actual drawing -- but I'm pretty sure neither one does, at least currently. I don't know whether they ever will either -- they might, but I doubt it's a real priority, since they already support OpenGL and Direct3D. For their purposes WPF provides little advantage.
Seeing as WPF actually uses DirectX under the hood and the fact that you use XAML to specify DirectX objects, WPF is by far the easiest solution.
Example coding a camera in xaml:
<PerspectiveCamera x:Key="Camera"
Position="0, 0, 4"
LookDirection="0, 0, -4"
UpDirection="0, 1, 0"
FieldOfView="30"/>
I have developed a quite large application using MFC. Naturaly, I used GDI for drawing, CCmdTarget for event routing, and the document-view architecture.
It was a convenient development path.
Now, the client is interested in converting this application to .Net.
I would prefer (and they too) writing the new product in C#.
The application displays and interacts with thousands of graphic objects, so
I figured going with GDI+, although seems natuaral, can cause performance issues,
So I am thinking of using OpenGL, specifically - OpenTK - as the graphics library (it's 2D).
I know that OpenGL works differently that these Windows APIs, which rely on Invalidation of portion of the screen. OpenGL has a rendering loop which constantly draws to the screen.
My question is:
Is this an acceptable way to go, thinking of:
performance - will the users need special graphics cards (hardware?). It is graphics intensive, but it's not a high-end game
printing and print preview - are these things complex to achienve?
multiple selection and context menus
Is this library goes well inside windows forms?
I don't think so. Use WPF if you can or DirectX if you can't.
I know it might not be fair but if I'm programming on .NET (microsoft) on windows (microsoft) I'd rather use DirectX ... which is also from microsoft.
As a side note: don't reinvent the wheel. Recoding user controls in open-gl can be very time consuming, if you do make sure you have a good reason.
In my experience developing CAD-like software, the benefits of OpenGL and DirectX are fast depth testing, smooth rotation and panning, lighting and powerful texture capabilities. Obviously there are other benefits but, despite what most tutorials would lead you to believe, implementing a rendering system using either of these APIs is a significant undertaking and should not be taken lightly.
Specifically:
If it is a 2D app and you already have it implemented in GDI then switching to GDI+ will be much easier. Additionally, on modern hardware, 2D GDI or GDI+ can be about as fast as 2D OpenGL or DirectX. And ultimately, the end-user probably won't notice the difference, especially with double buffered support in GDI+.
You do not need (and probably don't want) a continuous rendering loop for your app. In OpenGL and DirectX you can explicitly invalidate the window when your scene changes.
If you go with OpenGL or DirectX you will need to consider putting your objects into display lists or vertex arrays (buffers) for fast drawing. This is not difficult but managing objects in this way adds complexity to the system and will most likely significantly change the architecture of your rendering system.
Printing in either OpenGL or DirectX can also be tedious. On the one hand you can render to a bitmap and print that out. However, for high quality images you may want vectorized images instead, which are difficult to produce with either of these rendering frameworks.
I would also stay away from writing GUIs in OpenGL or DirectX...unless you're really looking for a challenge ;~)
Finally, and this is just an annoyance from an install perspective, the Managed DirectX run-time library that must be installed on the user's machine is around 100 MB.
I have no experience with C#, but I have once built a layer system for a drawing program that used openGL for rendering.
To make this layer I asked openGL for the current framebuffer and converted it to an image to use as a texture under the current canvas. So I guess from there its pretty easy to go to printing and print preview.
Direct X and Open GL much faster than GDI+.
You can also use an TAO framework as an alternative to OpenTK.