I am building a custom UI framework in WPF where I basically ditch as much of the built-in layout system and controls as I can. So far I have been branching off from UIElement directly, but since I am already doing the measure, arrange and rendering myself, I am thinking I could slice off more of the WPF legacy by getting even "closer to the metal" (especially when it comes to layout / rendering). How close is it possible to get while staying in managed code and not being afraid of doing the dirty work myself?
I am toying with a prototype concept on the side now where I only have one element inheriting from UIElement: a Root object, similar to a stripped down Canvas, that "hosts" the rest of my layout engine and channels relevant IInputElement benefits into it. From that point onward, all elements would be completely custom objects not inheriting from anything in WPF, but rendering directly into the DrawingContext of Root (in its OnRender method).
Now I'm wondering about the relative performance of having a WriteableBitmap root element and manually draw onto that instead, for example using WriteableBitmapEx for convenience. Not having anti-aliasing isn't an issue, neither is a custom hit testing system.
My thoughts are primarily that WriteableBitmap(Ex) does not have the privilege of any GPU acceleration gains and therefore will be [much] slower when large areas needs to be repainted / transformed.
I do have other needs for a "pixel-based-rendering-engine-in-the-engine", though, so I am still interested in some perspective on this.
Any insights?
Edit: And what about SharpDX in this context? Maybe once I'm at it I might as well go for a WinForms solution with a DirectX wrapper like SharpDX (..or.. I guess what I really should do is sign up for the whole C++ enchilada, but unfortunately I don't have time to start learning that in the midst of things)..
WriteableBitmapEx is quite fast, even when it just runs on the CPU. It's used in this high perf charting control: http://www.scichart.com
You should also checkout Direct3D indeed. You can get really good performance, but it really depends how it's used and that most draw operations are cached and the CPU-GPU communication is as lets as possible.
Related
There is a 3D simulation I made with helixtoolkit.wpf, but it is not effective at all in terms of performance. How can I adapt this project to SharpDX? I could hardly find any information about it on the internet. Is there a resource or shortcut you can recommend?
That would be a total rewrite. HelixToolkit and SharpDX is in no way compatible in scope.
HelixTookit is a wrapper around Wpf and provides a bunch of convenient controls and functions to easily display viewports with navigation etc.
SharpDX is a wrapper around Direct3D, so provides a much lower level access to the hardware. But you would need to write a lot of components yourself to be able to provide anywhere near the level of functionality of Helix. SharpDX is also no longer maintained, so you would spend a lot of time porting to a effectively dead technology.
As always with performance you should start with profiling. Is it really Helix3D that is the bottleneck? Or are you using it in a way that is inefficient? Before doing a major rewrite you should be certain you have explored all other options for performance optimization.
One thing you might try is to export your model to a file and open it in the windows 3D viewer, I suspect that uses the same underlying wpf code to display 3D models, so it should give a fair estimation of the possible performance.
I've been doing a lot of reading into WPF drawing and performance and it's apparent that some methods of drawing are better than others. I have however gotten confused with different people's terminology of things and just want to clarify one issue.
The system I'm working on has lots of gauges on a screen (exactly like a speedometer in a car). The scale and range indicators can change and are different on each gauge. Is it best to draw these in the xaml or in the .cs file behind it. The reason I'm asking is that we are starting to see performance issues in the system when a lot of gauges are on display and I'm trying to isolate the cause.
Currently it's drawn behind with each individual segment added like children.add(UIElement).
I'm not sure if placing them in the xaml or the code behind makes a difference - at the end of the day these objects get pushed onto the visual layer one way or another.
Your issue is more likely because you're using fully blown UIElement instances.
For performance enhancements, try using more light-weight objects, i.e. DrawingVisual
These objects are not as powerful as UIElements, so you may lose some functionality that you want to use that you'll need to reimplement another way.
This documentation should put you on the right track.
Can somebody shed some light on how to create c# custom controls from vc? I need to create some graphical controls which will be used in a C# project like the default controls, because performance is important and it's on a low performance windows CE device, I guess I have to do it in c/cpp.
The simple, straightforward answer is that you can't. Period. The Compact Framework doesn't support managed C++ (C++/CLI). Now I suppose you could create the UI component as a COM control, then hand-roll all of the COM interface stuff for the managed side, but that would be a nightmare to build, debug and especially deploy.
You're better off just dropping to unsafe code and using P/Invokes to the Win32 APIs you're after right in the C# code. For most things, you can achieve what you want and get good perf. If you have something that absolutely must be done in C for speed, then create a library that you pass in buffers to via P/Invoke. The Imaging library, for example, uses this type of mechanism for creating thumbnails, etc.
You can try to write a complete control in C and provide a very thin wrapper exposing what you need to control from say C#. It doesnt necessarily need to follow UserControl or Control's model if we are talking about Forms controls, which is somewhat complicated to get right, and where all the cost goes for those controls. Its very harsh.
You can also investigate WPF, which tries to get more done on the managed side, thus faster. It has its own complications. It will composite / "bitblit" usually fairly inteligently on its own, but goes overboard often, but its way faster (or can be) than a double buffer Forms control, which in the end will be doing the same composite in double buffer mode, but slower with a larger flurry of faux win message handling. (To grossly oversimplify)
So rather than just saying NO, i think those are your options. Again, it is possible to control at arms-length, a well-written C side render and get near native performance.
Edit:
I missed the Windows CE part of the question. My bad. I dont know if what I said will apply.
I assume you're talking about WinForms and not Silverlight.
You don't need to.
.NET on Windows CE performs JIT of CIL (unlike the Micro Framework which interprets it, like old-school Java). There is no real performance penalty of writing controls in C#. The most expensive operation is painting, and if you use C# or C++ then you'd be doing this with GDI, and it's inside GDI's function calls where the expensive operations lie, the only thing you'd be saving is the marshalling between Managed and Native territories, but that really does count for very little.
The only situation where you might want to use C++ to create a Windows CE GUI was if you were working with video or an animation framework (like Flash), and if you were doing that then you'd use C++ entirely and not use .NET for any of your GUI.
This is what I have to do:
To build a CAD-like application that loads a point cloud (i.e. thousands of 3D points representing a 3D object) from file, allows the users to manipulate the points (i.e. change the shape by moving the points), do a lot of calculations the points on the points (e.g. finding the intersection points between lines and surfaces, detect a point is above or under a surface etc., measure the distances between points, or points to surface etc.), and then save the modified points to file.
It also provides basic CAD-like UI features such as zoom in/out, pan the view, rotation the camera etc.
Speed is the major concern.
Instead of writing my own functions for matrix operation and defining my own point/line/surface classes, I would like to use existing libraries/APIs to do the job.
I know WPF, XNA and SlimDX provides the API to do 3D geometric calculations and all of them are finally calling DirectX, but I'm just newbie to all of them. I'm wondering:
Which one (or some other suggestion) could give better performance in speed.
My understanding about DirectX's 3D functions is that it mainly deals with gaming graphics / screen outputs, is it also suitable for data-level calculations(i.e. use the 3D functions to manipulate the point data, calculate the distances etc., but not outputting it on the screen)? By suitable, I mean if I create thousands of DirectX vertexes and mainpulate them, would it be much slower than using my own data types and structures?
Pls correct me if my understanding is wrong.
If I use WPF, do I need to use XNA as well? I'm kind of mixing up these two things.
The application is supposed to run in research lab's PC which doesn't have powerful gaming display card, so does it mean XNA is not preferred?
An suggestion about the technologies should be used for this application?
Thanks!!
========update
To make it clearer, the app will load ~108,000 points in 3D, and every points will form surfaces with other adjacent points, so roughly the the same number of 3D surfaces are involved (I'm not generating them at the same time). I will do a lot of 3D geometric and matrix calculations with the point and surfaces, such as intersection, interpolation, transformation etc. , so the speed of the "calculations" is my major concern. Most of the time I will only draw the final result to the screen and the drawing is mainly lines and points, the speed of "drawing" is not a big concern . so it is not really a graphic-intensive app, but a geometric-calculation-intensive app.
After reading the answer and comments, I think of two options:
store & calculate the data with primitive data-types, and convert data to the WPF/XNA/SlimDX data structures when drawing them on screen, or
use these API's data structures to store, calculation and drawing all those points.
which one is better?
Honestly, if performance is your
primary concern I would go with the
API that gets you closest to the
hardware. Less obfuscation = more
speed. In that case, from the
choices you've provided, SlimDX
is the best option, followed by XNA,
and lastly, WPF.
No, DirectX must use efficient data structures and algorithms. Think about it-- would games that utilize DirectX be able to run at a suitable framerate if all DirectX calculations were inherently slow?
No, WPF and XNA are mutually exclusive. WPF is a framework for creating responsive and intuitive user interfaces. XNA, on the other hand, is a framework for creating games.
Not necessarily. What it actually means is that WPF is not preferred, as WPF will offload a lot of work to compatible video cards. If WPF is unable to find a suitable video card, the CPU will take that work instead, resulting in poor performance.
As I said before, for a graphics-intensive application such as the one you have described, the closer you can get to the hardware is the better. Native DirectX or SlimDX are good options.
Have you considered developing your functionality as a plugin for an existing CAD environment?
AutoCAD, for example, has a very powerful c++ sdk (ObjectARX), it also provides a managed .NET API. You can use c# and WPF to develop your extensions. It has existing geometry libraries you can reuse.
Certainly AutoCAD has its price, but there are alternatives. For example BricsCAD. I'm not sure if BricsCAD provides a .NET api though.
Developing an application from scratch would take weeks if not months.
If I were to develop your functionallity as an AutoCAD plugin it would take me a day.
Consider if you really need to roll out own your own 'CAD' environment.
A few weeks ago, I checked out the limits of XNA. I want to know how much billboards (GPU accelarated) the engine in able to deal with. The result:
Pure XNA: 350k billboards
XNA as rendering context in WPF: 100k billboards
I do not realy know why the engine slow down when rendering to a WinFormHost control. Some debugging shows, that GraphcisDevice.Present()
I've created a workflow/flowchart style designer for something. At the moment it is using relatively simple Bezier curve lines to connect up the various end points of the "blocks" on the workflow.
However I would like something a bit more intuitive for the user. I want the lines to avoid obstacles like other blocks (rectangles) and possibly other lines too.
I prefer the bezier splines rather than polylines because they are prettier and seem to fit in better with the designer in general. But am willing to compromise if they are much harder to accomplish.
I know there is a whole load of science behind this. I've looked into things like Graphviz, Microsoft's GLEE and their commericial AGL (automatic graph layout) library.
GLEE seems to barely be production worthy. And their commercial alternative is, well, a commercial alternative... it's quite expensive.
Graphviz doesn't seem to have been ported to .NET in any way.
I have seen a polyline implementation used by Windows Workflow Foundation for its "freeform designer". And this works, just, but it is not really of production grade appearance.
I'm surprised there isn't some plug'n'play .NET library for this type of thing? Something like:
Point[] RoutePolyline(Point begin, Point end, Rectangle[] rectObstacles, Point[] lineObstacles);
I haven't tried it (although I'm a happy customer of their Gantt product), but ILOG have a similar tool here.
To quote:
The ILOG Diagram for .NET algorithms
share generic goals such as:
Minimizing the number of overlapping
nodes
Minimizing the number of link
crossing
Minimizing the total area
of the drawing
Minimizing the number
of bends (in orthogonal drawings)
Maximizing the smallest angle formed
by consecutive incident links
Maximizing the display of symmetries
Supporting incremental layout,
partial layout, subgraphs,
intergraph links and nested layouts
Perhaps worth a look, at least.
Diagram.NET is a free, open source diagramming library in C#. It hasn't been updated in quite some time, but it's certainly worth a look - there may something there which you can reuse.
http://www.dalssoft.com/diagram/
Are you limited to managed code only?
I did not have this restriction and the past and effectively integrated GraphViz with .Net. What we did was call an external process containing the natively compiled "dot" and parse the result in a .Net object model. It worked perfectly and was fast enough for our needs.
I'm sure you could do better and easier with C++/CLI today.