Very fast textbox needed
-
Hi everybody, I'm building a c# application that reads data messages from an external device at a rate of 1MBit/sec. I need to log in a window all messages. I tried to redirect console output to a textbox, but the textbox was not fast enough to update and a half of messages were lost. I have a thread that read continuously from the device and put messages on a buffer. A consumer thread read messages and pass them to the textbox. So...I need a very fast logging window and, if someone will give me some suggestion to speed up .Net controls it will be great for me.
-
Hi everybody, I'm building a c# application that reads data messages from an external device at a rate of 1MBit/sec. I need to log in a window all messages. I tried to redirect console output to a textbox, but the textbox was not fast enough to update and a half of messages were lost. I have a thread that read continuously from the device and put messages on a buffer. A consumer thread read messages and pass them to the textbox. So...I need a very fast logging window and, if someone will give me some suggestion to speed up .Net controls it will be great for me.
A textbox cannot 'lose' messages. You need to write code to cache the messages, that's where they are being lost. The textbox should just display them.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
A textbox cannot 'lose' messages. You need to write code to cache the messages, that's where they are being lost. The textbox should just display them.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
Thank you Christian... I would say that i can't add a new line to the textbox each 300-400 microsecond... If I'm not wrong you're suggesting me to bufferize a number of messages then update text in textbox only after this number, is it? Sorry for my bad english :)
-
Thank you Christian... I would say that i can't add a new line to the textbox each 300-400 microsecond... If I'm not wrong you're suggesting me to bufferize a number of messages then update text in textbox only after this number, is it? Sorry for my bad english :)
If you can't write to the control as fast as your data stream requires, even bufferizing hasn't got a prayer of helping you. You need to revise your design to use a control that can keep up with the stream. Why you aren't writing to a console isn't clear. I hope nobody is supposed to read all this at that rate... so why the text box?
-
Thank you Christian... I would say that i can't add a new line to the textbox each 300-400 microsecond... If I'm not wrong you're suggesting me to bufferize a number of messages then update text in textbox only after this number, is it? Sorry for my bad english :)
A list box has faster performance for adds than a textbox, but there's no UI control that can cope with a megabyte of data per second. The continual reallocation of its text container as it overflows will bring it to it's knees. When you're at 1meg and overflow, it will allocate 2 megs, and copy the old into the new. When the two meg container overflows it'll create a 4meg container and copy the existing 2 megs. Even a listbox will break well before the meg point with highspeed data. For logging mouse messages which are at most several hundred per second I was only able to cache and display 1000 messages before I began to have performance issues. Loading ~500k messages once took over a minute to complete.
-- Rules of thumb should not be taken for the whole hand.
-
Thank you Christian... I would say that i can't add a new line to the textbox each 300-400 microsecond... If I'm not wrong you're suggesting me to bufferize a number of messages then update text in textbox only after this number, is it? Sorry for my bad english :)
You may be able to use DirectX or OpenGL. I know it seems like overkill to use a 3D engine to display simple text, but graphics cards are built for speed. Of course, you will have to handle all aspects of the display yourself. Disclaimer: I've no clue how fast text can be written in either DirectX or OpenGL.
-
Hi everybody, I'm building a c# application that reads data messages from an external device at a rate of 1MBit/sec. I need to log in a window all messages. I tried to redirect console output to a textbox, but the textbox was not fast enough to update and a half of messages were lost. I have a thread that read continuously from the device and put messages on a buffer. A consumer thread read messages and pass them to the textbox. So...I need a very fast logging window and, if someone will give me some suggestion to speed up .Net controls it will be great for me.
Hi, I concur with Dan: a ListBox is a lot faster than a TextBox when large amounts of text are involved. But then you must be aware a Windows system is not a real-time system, under some circumstances (garbage collection, floppy access, antivirus activated, high network traffic, ...) it will be unable to cope with an external device producing data at a high and uninterruptible rate. IMHO you should provide at least one of the following: - a sufficient buffer inside the external device; - a start/stop communication protocol; - a retry facility Some additional thoughts: 1. maybe you are only interested in the last N lines of information, in that case organize the listbox in such a way that it throws away the oldest lines when new lines come in, avoiding it to grow without limit. 2. once a control contains 100,000 lines of text it becomes practically useless: it gets very hard to navigate, you typically dont find anything anymore. 3. you may reduce the CPU load caused by the listbox by using AddRange() instead of Add() effectively adding say 10 lines at once; or by using SuspendLayout()/ResumeLayout() so it gets redrawn only every say 10 lines. 4. you may improve performance (at the expense of more code) by disconnecting your data source and the listbox: have your own buffer scheme (preferable a circular buffer) holding the last N lines of text, which are NOT added to a listbox; and a listbox (or a simple Panel) which acts as a low-frequency view on say a sliding windows of a fraction of those N lines. :)
Luc Pattyn [My Articles]
-
Hi, I concur with Dan: a ListBox is a lot faster than a TextBox when large amounts of text are involved. But then you must be aware a Windows system is not a real-time system, under some circumstances (garbage collection, floppy access, antivirus activated, high network traffic, ...) it will be unable to cope with an external device producing data at a high and uninterruptible rate. IMHO you should provide at least one of the following: - a sufficient buffer inside the external device; - a start/stop communication protocol; - a retry facility Some additional thoughts: 1. maybe you are only interested in the last N lines of information, in that case organize the listbox in such a way that it throws away the oldest lines when new lines come in, avoiding it to grow without limit. 2. once a control contains 100,000 lines of text it becomes practically useless: it gets very hard to navigate, you typically dont find anything anymore. 3. you may reduce the CPU load caused by the listbox by using AddRange() instead of Add() effectively adding say 10 lines at once; or by using SuspendLayout()/ResumeLayout() so it gets redrawn only every say 10 lines. 4. you may improve performance (at the expense of more code) by disconnecting your data source and the listbox: have your own buffer scheme (preferable a circular buffer) holding the last N lines of text, which are NOT added to a listbox; and a listbox (or a simple Panel) which acts as a low-frequency view on say a sliding windows of a fraction of those N lines. :)
Luc Pattyn [My Articles]
Thanks a lot to everybody!!!!