I'v created a Notepad-like application and if I load a 1MB file into the textbox, it takes about 1 minute. The Visual Studio Binary editor displays lines, Hex, and ascii versions in a fraction of a second. How do they get the data into the textbox so quickly? Thanks
+8
A:
They only read enough of the file to display what is viewable on screen. In other words, if your UI can only display 100 bytes at a time, you only need to read 100 bytes to fill the screen. If the user scrolls the window, you have to read additional bytes to fill in the missing pieces.
Chris Hafey
2010-04-25 14:06:21
lol everyone deleted their posts :-p
Milo
2010-04-25 14:11:19
Well reading is not the problem, its the winGui that is... thanks though
Milo
2010-04-25 14:16:33
Use another GUI widget - some will fire events when the need more data
Chris Hafey
2010-04-25 14:43:43
A:
I don't mean to be rude. Just hope to help and clarify: You mentioned in a reply that reading is not the problem and that the win32 guy was the problem. But I really doubt that.
First things first, disc access is monumentally slow compared to anything GUI related. Even if you set an EDIT box to contain some very large amount of text it's essentially just a memcpy and a repaint.
There is a bit of processing involved. The string must be walked through to find newlines. And if you are word-wrapping it would have to keep adding the next letter's width until you go beyond the allowed width. But both of those are pretty darn fast compared to reading from disc.
So are you really, truly sure it is a GUI speed issue and not a reading issue? Can you provide times on both? I just find it so hard to believe that the GUI is the issue here...
ProgramMax
2010-05-05 07:59:43
Then how come in cmd I'm able to output it in a second? I also added a messagebox right after the buffer is filled and this was lightening fast... I promise it is the paint event that kills it because GDI sucks.
Milo
2010-05-05 12:00:19
That's very difficult for me to answer without seeing your code. There could be a million things slowing it down. I can't just guess at what's going on.If you are reading a byte at a time and the appending the byte you are doing that many memcpys, walks, word-wrapping tests, and paints. That would be slow. But even then, the problem isn't because the GUI is slow. It's because you are telling it to do 1,048,575 times the work it should have to do (1MB file).
ProgramMax
2010-05-05 18:49:55