I would like to write a simple ray tracer using WPF. It is a learning project and thus I favour configurability over performance (otherwise I'd go for C++).
I still want relatively fast pixel drawing. A previous question on StackOverflow contains code to achieve this in WPF, by obtaining a GDI bitmap. From the relatively little I know about Windows programming,
GDI is slow
DirectX is fast
WPF uses DirectX underneath (not sure which parts of WPF though)
Is it possible to obtain pixel-level access using DirectX (not GDI) through the WPF Canvas (or similar)?
I will also consider suggestions for incorporating DirectX API calls within a WPF window (alongside other WPF controls) if that is possible.
Thanks in advance.
Interesting, but with raytracing, writing the pixels to the screen will (should) not be the slow part. You can use WriteableBitmap for the purpose, though. It's certainly quick enough for what you want.
http://msdn.microsoft.com/en-us/library/system.windows.media.imaging.writeablebitmap.aspx
(For info, I use it in this emu/IDE - http://0x10c-devkit.com/ - and it can refresh a low res display with great performance. There's the source to that on the github repository, the LEM1802 plugin.)
Ah, this bit: https://github.com/kierenj/0x10c-DevKit/blob/master/PluginAPI/NyaElektriska.LEM1802/GPU.cs - see UpdateDisplay.
Another solution is WriteableBitmapEx. It extends the builtin WriteableBitmap.
There is an open Source Project Called Direct Canvas wich is A hardware accelerated, 2D drawing API that supports vector graphics, multimedia files, extensible pixel shaders, blending modes and more!
http://directcanvas.codeplex.com/
Demo http://www.youtube.com/user/jdollah69#p/u
Related
As part of my audio libary i would like to create a sample visualisations.
I know how I get the values I want to draw like fft results and so on.
But the main problem is that I don t know whats the best way to draw them. I have quite a lot of experience in using wpf but I never had to do something like this. What should I use to keep performance as good as possible?
There are a number of different approaches you can take, depending on the quality you need, memory usage, and performance....here are just some.
create a new object derived from FrameworkElement, and then inside draw the "visual" aspect dynamically by drawing onto a DrawingContext during OnRender. Drawings have a much lower overhead than other WPF elements such as Shapes, Image, etc. However, it still may not scale well if you have 1000s of elements. http://msdn.microsoft.com/en-us/library/ms751619.aspx
WriteableBitmapEx....it will give you the drawing primitives you need to write into a Bitmap directly. http://writeablebitmapex.codeplex.com/ .. see this for some demos which are spookily similar to what you would do for an audio visualization. http://blogs.claritycon.com/blog/2011/03/advanced-animation-animating-15000-visuals-in-silverlight-2/
use DirectX with Direct2D. This offers DirectX like performance, but you would need to use COM interop or C++/CLI code wrappers to make it available to your .NET C# code. http://www.codeproject.com/Articles/113991/Using-Direct2D-with-WPF
Some other links:
http://jeremiahmorrill.wordpress.com/2011/02/14/a-critical-deep-dive-into-the-wpf-rendering-system/
I need to speed up my image viewer, and wondering if I should be looking into creating my own DirectX control to do so.
My image viewer displays medical images. They can be pretty large. We're talking 55mb when it comes to mammography. The pixel data is 16bit greyscale stored in a ushort array. Without getting into the gory details, my current approach is loading the pixel data into an ImageSource, and using the WPF Image control.
I've never done anything with DirectX. Is it worth diving into it? Would it be any faster than the native WPF stuff? If so how significantly? Or, should I just forget about DirectX and look into areas where I can improve my current approach?
Before somebody says so, I know WPF utilize DirectX. I'm wondering If removing the WPF layer and writing the DirectX myself will improve performance.
I have some experience drawing multi-gigabyte satellite and chart imagery. Working with imagery around 55MB should probably work okay even without trying to optimize it too much. You haven't really given enough detail to recommend one alternative over the other, so I will give my opinion on the pros and cons.
Using 2D windows APIs will be the simplest to implement and should always be fast enough if you don't need to rotate and simply want to display an image and zoom and pan around. If you treat it as one large image the performance will not be as good when you zoom out if you are drawing with halftoning to give a nice smooth image. This is because it will effectively have to read all 55mb of image every time it draws.
To get around this performance issue you can make multiple bitmaps, effectively mip-mapping your image. As you zoom out you can pick the reduced resolution image closest to the resolution you are trying to draw . If you are not familiar with mip-mapping here is a Wikipedia link:
http://en.wikipedia.org/wiki/Mipmap
Implementing it with DirectX will be 10x as difficult. Different graphics hardware has different maximum texture sizes. Most likely you will need to break your image up in to multiple textures to draw and you will also have to keep track of render states, viewing matrices, etc.
However, if you do use DirectX, you can implement lots of real-time photo adjustments You can do real-time rotation by simply adjusting view matrices. You can do real-time contrast, brightness, gamma, and sharpness easily in a pixel shader.
There are two other API's I might suggest. If you are willing to limit yourself to Vista or later then Direct2D would be a little simpler than Direct3D. Also if you ever will need to implement it on a non-windows platform I would suggest using OpenGL instead. My current project is in Direct3D because a few years ago when we started it OpenGL was falling behind and I didn't forsee the popularity of Android devices. I now wish we had used OpenGL instead.
Try profiling to see where WPF is spending its time. Are you displaying the images at their native resolution? If not it might be worthwhile to do some preprocessing and create 1/2 resolution versions.
I am starting a new project to show live video in a Windows form from an attached web cam and overlay that video with windows controls (buttons etc). Additionally I would like to do some image correction to remove distortion on the fly and do some edge detection.
I'm confused as to which library might be best suited for this.
OpenCVSharp - Can handle the correction / detection, not sure if overlay / live feed is possible.
DirectShow/DirectShow.Net - Do I need to code filters up for the
overlay, how to handle edge detection?
AForge.net - It's been recommended but I'm not sure it is as capable
Does anyone have experience of these or other libs that might be suitable for access from .Net?
If you only want to work with the vision part then AForge.net is your best bet. I have used it in the past and it was pretty good for video/feed stuff. Don't expect to do something with your audio later on though since AForge.NET only supports Vision related stuff. Personally I wouldn't use DirectShow since that is pretty old and sometimes requires you to do some complex interop tricks to get what you want. If you want to go the DirectShow way at least use DirectShow.NET.
I believe you can accomplish that with OpenCVSharp and the instructions from transparent image overlay.
I've been writing a small desktop gadget-type application that displays scrolling text along the bottom of the screen (Similar to the old CNN news ticker), however the performance of GDI is just unsatisfactory (As high as 8-12% on a quad core and 20% on a single core) even after I've attempted to clean out bottlenecks.
I was considering using OpenGL instead to render everything, but I don't know if that is a reasonable option to require users to have hardware acceleration for a tiny app like this.
Does anybody have any input on this?
If you're comfortable with using OpenGL and your intended users are happy with the additional dependencies that OpenGL brings then I say go for it. :)
In terms of staying with GDI, I'd make sure you're rendering the text a few times as possible (through such techniques as rendering to bitmap and just scrolling that instead).
If neither one of those two options sounds appealing then there's always DirectX.
You could write the app in WPF and let WPF handle the acceleration for you (it's backed by DirectX).
I wouldn't want to install open gl for a program like that. You say that you "attempted" to eliminate the bottlenecks, but it does not sound like you succeeded. Like lzcd mentioned, there are other ways to scroll text than to repaint it constantly. Why not just draw to a bitmap and scroll that?
See above.
I need to move my bitmaps around a Form, or perhaps inside a PictureBox in a form. I have not been able to find any tutorials on this specific subject, and even the base GDI+ stuff is a bit confusing. I am looking for a simple and THOROUGHLY explained way on how to do this.
I am needing this for a rendering engine for an 8-bit game I am collaborating on.
GDI+ may not be the best option.
Sprites are generally drawn using "blitting". However, I've read (perhaps outdated?) claims that GDI+ blit operations are slow because they're not hardware accelerated.
If this is 8-bit game rendering, maybe you don't care - but maybe you could use SDL.NET.
In particular, try this tutorial. You should probably follow that first bit of advice (do the hello world first) but this is worth a skim through first to see if it fits.
EDIT - actually, there's not much tutorial there ATM. The main SDL docs (for the C version) are probably OK, but it's still a bit of a pain. Oh well.