16 channel Real Time signal rendering: Should I go for DirectX?

I'm refurbrishing an old VB6 application that displays up to 16 signals, at 100 samples per second, along with some icons on the screen. The user decides on the on-screen resolution by means of a zoom function key.

Now in the design phase, I need some more information to decide on taking Direct-X or GDI+ path.

I've been going through several sample applications, and so far, I've got the feeling that Direct-X is suited to heavily drive the graphics processor in order to render very fast moving sprites and meshes. Instead, GDI+ is a more generic interface layer in between the old API's and the application. Not as efficient as Direct-X.

The question is: Given that the curves move so fast on screen, should I better take Direct-X instead of GDI+ Is there a way to very quickly lit a pixel to the right of the window and then shift the entire content one pixel to the left

Thanks in advance for your help.



Answer this question

16 channel Real Time signal rendering: Should I go for DirectX?

  • Pat Jones

    I'll test the code you forwarded, which I'm sure it'l help me on my decision making.

    Thanks Sergey.


  • Rido

    Hi Sergey!, and thanks for your answer.

    I've been working in the past with API, and I'd rather avoid them for this application, but if there is a way to shift and render at 30fps using GDI+, I'd beg you to give me a clue about how to do that.

    In the other hand, I wouldn't mind to move to DirectX, though I agree with you that the level of complication is higher. The question, again is whether it is feasible to draw a line and shift the screen content in a quick way. The examples I've been through so far show how to draw complex primitives and then transform them in may ways, but my code is not relying on a rediced number of non-changing 3d objects: Instead, my code needs to add a dot to the right side of the screen very quickly, after shifting the entire windows content. I suppose that this is possible, but being a beginner, finding no approximate examples, and meshes, transforms, cameras and lights still being a mess to me, it's difficult to take the decission.


  • pedrojr

    Hi!

    Human eye works at 24 FPS. Movies shown at 30 FPS. You can use this in your design - make app that runs at 30 FPS, 30 times per second invalidate screen and your rendering code must take last snapshot to draw (multithreading I assume, worker thread just generate snapshot and UI thread copy it into itself 30 times per second). Then you can render whatever you want - GDI+ slower, but much easier to implement than DirectX.

     

    As for quick shift old content - you may use Win32 API ScrollWindowEx() function. But you still need to handle stuff about invalidation.

    Or you may render to own bitmap and 30 times per second render it in single call using GDI+.



  • Brett Nieland

    Hi Ralph!

    well. I suppose I can use a buffer to slow down the changes on screen, for them to be displayed at an approximate rate of 20 per second


  • Gargamel

    Do you have to update the screen 100 times per second too or can the display update slower



  • maehler

    Thanks, ilatzis. I'll give it a try.
  • ANeelima

    if you comment out the //ControlStyles.Opaque |

    SetStyle(

    ControlStyles.AllPaintingInWmPaint |

    //ControlStyles.Opaque |

    ControlStyles.UserPaint |

    ControlStyles.OptimizedDoubleBuffer

    , true);

    maybe you 'll see slightly faster performance when the window is maximized


  • Wolfgang Rockelein

    I think 20-30FPS is what you can achieve even in GDI+. Few months ago I wrote app that render hundreds of strings with 40 FPS and never seen a problem with speed. Just use call like this:

    SetStyle(ControlStyles.AllPaintingInWmPaint | ControlStyles.Opaque | ControlStyles.UserPaint | ControlStyles.OptimizedDoubleBuffer, true);

    If you want to make shift & render - use ScrollWindowEx() to scroll your window a little and render only new part of the content. Check MSDN for details on that function. But again - here you will need to make your rendering code to be able to restore whole image on screen, not just scrolled one.

    You can try to work with bitmap in memory, Bitmap.LockBits() can be used to lock it and do manual changes. OnPaint() will simply render this bitmap in the invalidated area.

    I just try to create rough app to render 1000 random lines in 300x300 form. Well, measures shows that it can run at 20-80FPS (depend on level of optimization, for example first time I create Pen object each time I draw, second use precreated Pen). When I add call to DrawLines() I get 120 FPS. So as you see, you can prepare an array of points in background and call DrawLines() to render them quickly enough. Also I use double buffering here, but I think if your code render into offscreen bitmap and display this bitmap 20-30 times per second - things will be quick enough.

    Try make some prototype and measure speed. Anyway this is less time than starting DirectX app.

    Here is that code:

     

    public partial class Form1 : Form

    {

    public Form1()

    {

    SetStyle(ControlStyles.AllPaintingInWmPaint | ControlStyles.Opaque | ControlStyles.UserPaint | ControlStyles.OptimizedDoubleBuffer, true);

    InitializeComponent();

    }

    protected override void OnPaint(PaintEventArgs e)

    {

    aPerformanceCounter counter = new aPerformanceCounter();

    counter.Start();

    Random r = new Random();

    Point[] points = new Point[1000];

    for (int i = 0; i < points.Length; i++)

    {

    points[ i ] = new Point(r.Next(ClientSize.Width), r.Next(ClientSize.Height));

    }

    e.Graphics.DrawLines(Pens.AliceBlue, points);

    counter.Stop();

    Text = string.Format("FPS = {0:n4}", 1 / counter.Seconds);

    }

    private void timer1_Tick(object sender, EventArgs e)

    {

    Refresh();

    }

    }



  • 16 channel Real Time signal rendering: Should I go for DirectX?