Hi,
I am facing a performance issue in CRichEditCtrl under Wine. My application reads data from a *.dat file and displays it in the CRichEdit editor. When I try to open large data files, it takes a lot of time(around 4-5 minutes) to open the file.
I checked the code and found that, in Wine, the richedit editor streams-in the data in a block of 4096 bytes. On Linux, the read request to the file is routed via Wine. For every block of 4096 bytes that are read, the system makes a back and forth call between the callback function in the application and Wine code(ME_StreamInFill() in dlls\riched20\editor.c), which causes the delay.
If anyone stumbled upon the similar issue, what should be the solution to this.
Thanks Renu Rajput
Hello,
On 16/11/06, Renu Rajput renu.rajput@gmail.com wrote:
I am facing a performance issue in CRichEditCtrl under Wine. My application reads data from a *.dat file and displays it in the CRichEdit editor. When I try to open large data files, it takes a lot of time(around 4-5 minutes) to open the file.
I checked the code and found that, in Wine, the richedit editor streams-in the data in a block of 4096 bytes. On Linux, the read request to the file is routed via Wine. For every block of 4096 bytes that are read, the system makes a back and forth call between the callback function in the application and Wine code(ME_StreamInFill() in dlls\riched20\editor.c), which causes the delay.
4096 bytes is the same that MS uses. In fact, we have other problem, it's the speed of insertion of large text chunks (especially without any formatting) to the editor storage from the RTF/plaintext reader. It should be optimized. And also, MS RichEdit, starting from version 3, displays the first page of large loaded text very quick, and you can work with it and see how vertical scrollbar thumb gets smaller and smaller and smaller while the text is read into editor storage in the background. We should add that, too.
The size of the buffer does not really matter here...
If anyone stumbled upon the similar issue, what should be the solution to this.
Optimize internal text storage (many small mallocs and reallocs ;( ). Optimize text insertion code. Do formatting/layout tasks in the background.
-- Ph.
Hello,
On 16/11/06, Renu Rajput renu.rajput@gmail.com wrote:
I am facing a performance issue in CRichEditCtrl under Wine. My application reads data from a *.dat file and displays it in the CRichEdit editor. When I try to open large data files, it takes a lot of time(around 4-5 minutes) to open the file.
I checked the code and found that, in Wine, the richedit editor streams-in the data in a block of 4096 bytes. On Linux, the read request to the file is routed via Wine. For every block of 4096 bytes that are read, the system makes a back and forth call between the callback function in the application and Wine code(ME_StreamInFill() in dlls\riched20\editor.c), which causes the delay.
4096 bytes is the same that MS uses. In fact, we have other problem, it's the speed of insertion of large text chunks (especially without any formatting) to the editor storage from the RTF/plaintext reader. It should be optimized. And also, MS RichEdit, starting from version 3, displays the first page of large loaded text very quick, and you can work with it and see how vertical scrollbar thumb gets smaller and smaller and smaller while the text is read into editor storage in the background. We should add that, too.
The size of the buffer does not really matter here...
If anyone stumbled upon the similar issue, what should be the solution to this.
Optimize internal text storage (many small mallocs and reallocs ;( ). Optimize text insertion code. Do formatting/layout tasks in the background.
-- Ph.