http://bugs.winehq.org/show_bug.cgi?id=13355
Summary: Richedit very slowly open big text files Product: Wine Version: 1.0-rc1 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: nx@operamail.com
Richedit wery slowly open big text files (about 700 KB an biggers) while in Windows XP same program million times faster open same big's file.
http://bugs.winehq.org/show_bug.cgi?id=13355
--- Comment #1 from Juan Lang juan_lang@yahoo.com 2008-05-22 13:16:28 --- Please attach a sample file.
http://bugs.winehq.org/show_bug.cgi?id=13355
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|major |minor
--- Comment #2 from Vitaliy Margolen vitaliy@kievinfo.com 2008-05-22 13:40:45 --- Doesn't qualify to be major - it works with minor issue. Where are you opening this file? With what program? What file? Please attach example.
http://bugs.winehq.org/show_bug.cgi?id=13355
--- Comment #3 from Alikas nx@operamail.com 2008-05-23 04:23:45 --- Created an attachment (id=13269) --> (http://bugs.winehq.org/attachment.cgi?id=13269) Program who very slowly open big files thourth wine
Run govorenie.exe with wine and click '^' button. Then open some big (about 1 MB) text file and this program wery slowly (more than 5 minutes) in my computer thourht wine open or not open while on Windows XP it open after 2-5 seconds.
http://bugs.winehq.org/show_bug.cgi?id=13355
--- Comment #4 from Alikas nx@operamail.com 2008-05-23 04:31:23 --- Created an attachment (id=13270) --> (http://bugs.winehq.org/attachment.cgi?id=13270) Text file who govorenie.exe very slowly open
http://bugs.winehq.org/show_bug.cgi?id=13355
--- Comment #5 from Alikas nx@operamail.com 2008-05-23 22:49:58 --- About 700 KB file govorenie.exe open on my computer after 28 seconds. If minimaze and restore govorenie.exe using wine with this, about 700 KB, opened file, then it never normally restore. I wait 1 hour and govorenie.exe not compleatly restored! So I turn off computer, because and computer working at this time (after restore operation) very slowly, that in virtual method very hard, I think, turn off computer (I turn off computer in not virtual method).
http://bugs.winehq.org/show_bug.cgi?id=13355
Alikas nx@operamail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.0-rc1 |1.0-rc5
http://bugs.winehq.org/show_bug.cgi?id=13355
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.0-rc5 |1.0-rc1
--- Comment #6 from Dmitry Timoshkov dmitry@codeweavers.com 2008-06-19 06:23:43 --- Please don't change an originally reported version (especially without any explanation).
http://bugs.winehq.org/show_bug.cgi?id=13355
--- Comment #7 from Alikas nx@operamail.com 2008-06-21 12:32:41 --- (In reply to comment #6)
Please don't change an originally reported version (especially without any explanation).
But why? I change because in wine 1-rc1, wine 1-rc2, wine 1-rc3, wine 1-rc4, wine 1-rc5, wine 1.0.0 then inonify govorenie.exe with text size about 700 KB and try restore it, then it not restore or then close govorenie.exe with opened about 700 KB text size and try run again govorenie.exe then it not show and after about 30 seconds computer very slowly work while on Windows XP fast restore after minimize and after close govorenie.exe with 700 KB text, then run govorenie.exe it (govorenie.exe) show after 1-5 seconds.
http://bugs.winehq.org/show_bug.cgi?id=13355
James McKenzie jjmckenzie51@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jjmckenzie51@earthlink.net
--- Comment #8 from James McKenzie jjmckenzie51@earthlink.net 2008-10-26 19:52:29 --- Please report the problem with the original version you detected the problem with and then update with success/failure of any version you subsequently reported with. This allows developers to test with the appropriate version you discovered the problem with. It could be possible that someone else reported success with a lesser version and the problem appeared with the original reported version (called a regression of available functionality. Now that this explanation is given, I will request that you run the program with the following command line from the installed to directory for this program:
WINEDEBUG=+richedit wine govorenie.exe testfile.txt 2>&1 /tmp/govorenie.log
This should be a very large file and will need to be bzipped or gzipped.
Thank you.
James McKenzie
http://bugs.winehq.org/show_bug.cgi?id=13355
--- Comment #9 from Alikas nx@operamail.com 2008-10-29 00:36:13 --- That problem still is in wine-1.1.7. govorenie.exe not suport, I think, opening files like that: govorenie.exe testfile.txt. But it open last opened text if it (govorenie.exe) run .from it directory.
http://bugs.winehq.org/show_bug.cgi?id=13355
--- Comment #10 from Alikas nx@operamail.com 2008-10-29 00:45:27 --- And govorenie.exe not have install directory. Yuo can download it and try yuoself. This program I create. Yuo want, that I give this program code?
http://bugs.winehq.org/show_bug.cgi?id=13355
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #13270|text/plain |application/rtf mime type| | Attachment #13270|15.txt |15.rtf filename| |
http://bugs.winehq.org/show_bug.cgi?id=13355
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Component|-unknown |richedit Ever Confirmed|0 |1
--- Comment #11 from Austin English austinenglish@gmail.com 2008-10-29 09:46:23 --- (In reply to comment #10)
And govorenie.exe not have install directory. Yuo can download it and try yuoself. This program I create. Yuo want, that I give this program code?
That would be helpful.
Riched20 works around it.
http://bugs.winehq.org/show_bug.cgi?id=13355
--- Comment #12 from Alikas nx@operamail.com 2008-10-29 12:18:12 --- Created an attachment (id=16968) --> (http://bugs.winehq.org/attachment.cgi?id=16968) govorenie.exe source code
This code create richedit control, who not good work on Wine, but good work on Windows XP:
LoadLibrary("Riched32.dll"); ///* LoadLibrary(TEXT("Msftedit.dll")); //*/ hwndEdit= CreateWindowExW(0, L"RICHEDIT50W",NULL, ES_MULTILINE |ES_NOHIDESEL| WS_VISIBLE | WS_CHILD | WS_TABSTOP| WS_VSCROLL, 0, 0, 0, 0, hwnd, NULL, (HINSTANCE) GetWindowLong(hwnd, GWL_HINSTANCE), NULL);
This code open file and copy this file content to hwndEdit window:
if((HWND)lParam ==op) { OPENFILENAME ofn; char szFile[260]; ZeroMemory(&ofn, sizeof(ofn)); ofn.lStructSize = sizeof(ofn); ofn.hwndOwner = hwnd; ofn.lpstrFile = szFile; ofn.lpstrFile[0] = '\0'; ofn.nMaxFile = sizeof(szFile); ofn.lpstrFilter = "All\0*.*\0Text\0*.TXT\0"; ofn.nFilterIndex = 1; ofn.lpstrFileTitle = NULL; ofn.nMaxFileTitle = 0; ofn.lpstrInitialDir = NULL; ofn.Flags = OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST; if (GetOpenFileName(&ofn)==TRUE) { hFile = CreateFileA(ofn.lpstrFile, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, 0); if(hFile != INVALID_HANDLE_VALUE) { DWORD dwFileSize; dwFileSize = GetFileSize(hFile, NULL); if(dwFileSize != 0) {tk = (LPSTR)GlobalAlloc(GPTR, dwFileSize + 1); DWORD dwRead; ReadFile(hFile,tk, dwFileSize, &dwRead, NULL); wtk=new WCHAR[dwFileSize + 1];
MultiByteToWideChar(1251,0,tk,-1,wtk,dwFileSize + 1);
SetWindowTextW(hwndEdit,wtk); SendMessage(hwndEdit,EM_SETMODIFY,true,0); GlobalFree(tk);delete[] wtk; } } CloseHandle(hFile); SetCurrentDirectory(bdir); } }
http://bugs.winehq.org/show_bug.cgi?id=13355
--- Comment #13 from Alikas nx@operamail.com 2008-10-29 12:33:43 --- Govorenie.exe open only text (.txt) files. Rtf files it not suport.
http://bugs.winehq.org/show_bug.cgi?id=13355
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #16968|text/plain |application/zip mime type| |
http://bugs.winehq.org/show_bug.cgi?id=13355
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source, testcase
http://bugs.winehq.org/show_bug.cgi?id=13355
Dylan Smith dylan.ah.smith@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dylan.ah.smith@gmail.com Keywords|download, source, testcase |
--- Comment #14 from Dylan Smith dylan.ah.smith@gmail.com 2008-10-29 19:36:30 --- == Diagnosis ==
I looked into it, and I found that most of the time was spent wrapping the text. The more wrapping that occurs, the slower it takes, so it will take less time with a smaller font size or larger window.
I tried to find out what was taking a long time with wrapping, and I noticed that it was wrapping the entire document 4 times when handing WM_SETTEXT.
1. The text is wrapped as required when it is initially set in WM_SETTEXT.
2. After the text is set ME_UpdateScrollbar is called while processing WM_SETTEXT. Previously there was no scrollbar shown, and the wrapped text is larger vertically than the window, so the scrollbar is shown with ShowScrollBar. This sends a WM_SIZE message to the richedit control where it unconditionally wraps all the text.
3. After wrapping all the text while processing WM_SIZE, ME_UpdateScrollbar is called again. Since this WM_SIZE message is being processed immediately, the scrollbar state stored in the richedit control has not been updated yet, so the bScrollBarWasVisible variable is set to TRUE, and it calls ShowScrollBar (which does nothing) and then wraps all the text.
4. Once WM_SIZE is finished, ME_UpdateRepaint continues. As mentioned in #3, all the text is wrapped after calling ShowScrollBar.
== Proposed Solution ==
There are a few mistakes the code made that could be corrected: 1. WM_SIZE should only re-wrap the document if the horizontal width changes. 2. ME_UpdateScrollbar should call ShowScrollBar after updating the it's internal copy of the scrollbar state. 3. ME_UpdateScrollbar should use the fact that WM_SIZE is called by ShowScrollBar (although this should be tested to ensure it is consistent with Windows)
This would still leave 2 re-wraps, but the first one was only needed to find out that scrollbar would be shown. This first re-wrap could be interrupted when it gets to a paragraph that is below the end of the view, and realizes the scrollbar will be shown. This would only leave a relatively small overhead in wrapping a large document.
Lastly, I noticed that a lot of the time was probably wasted on memory allocated, deallocation, and copying text. This is because paragraphs are split into runs, where a run is a continuous string of text (i.e. not spanning multiple lines) with the same style (e.g. font, size, weight, etc.). Each re-wrap consists of two phases, one is joining the runs as if they are on the same line, and the second is splitting the runs at line breaks.
Splitting runs means the string is split into two chunks of memory, where the second one is newly allocated, and the text in the string after the split is copied into the newly allocated memory. Each split is independent, so this is repeated for each line of a paragraph.
This leads to excess memory being allocated since run for the first line of a paragraph will have enough space for all the lines of the paragraph. The second line will have enough space for all but one of the lines of the paragraph... and so on. This leads to allocating an amount of memory of approximately N*(N/2) compared to N for the text itself. The memory copying for the split happens in a similar manner, with the first step involving copying all but the first line of the paragraph into the memory for the second line.
This memory allocation, deallocation and copying of text could be cut down if the same string could be shared amongst multiple runs (lines in this case) in a paragraph. The run would then contain a pointer to a position in the string, the style of the text, and any other information about how to display that section of the string.
This would avoid a lot of processing, but would need some redesign of the code to manage it properly (e.g. you can't free the memory for the string of one run independently of the others). The simplest solution would be to use one string per paragraph. This may slow insertions for large paragraphs, but it would make up for it with the less time needed to wrap the paragraph.
http://bugs.winehq.org/show_bug.cgi?id=13355
--- Comment #15 from Austin English austinenglish@gmail.com 2008-10-29 20:05:07 --- Why did you remove those keywords?
http://bugs.winehq.org/show_bug.cgi?id=13355
Dylan Smith dylan.ah.smith@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source, testcase
--- Comment #16 from Dylan Smith dylan.ah.smith@gmail.com 2008-10-29 21:03:43 --- (In reply to comment #15)
Why did you remove those keywords?
Sorry, I started making my comment before you added them. I didn't realize it would remove them when I posted.
http://bugs.winehq.org/show_bug.cgi?id=13355
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de
--- Comment #17 from André H. nerv@dawncrow.de 2009-08-16 11:08:11 --- dup of Bug 6813?
http://bugs.winehq.org/show_bug.cgi?id=13355
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
--- Comment #18 from Bruno Jesus 00cpxxx@gmail.com 2012-03-01 23:52:18 CST --- Still present in 1.4-rc5 by using the attached files.
https://bugs.winehq.org/show_bug.cgi?id=13355
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |imwellcushtymelike@gmail.co | |m
--- Comment #19 from Ken Sharp imwellcushtymelike@gmail.com --- In Wine 1.7.45 this took less than ten seconds on my machine. Can some else please test and comment?
Increasing the size of the window is fairly slow too. I assume for the same reasons.
https://bugs.winehq.org/show_bug.cgi?id=13355
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED
--- Comment #20 from Ken Sharp imwellcushtymelike@gmail.com --- (In reply to Ken Sharp from comment #19)
In Wine 1.7.45 this took less than ten seconds on my machine. Can some else please test and comment?
No response. Opened much, much larger files in a fraction of a second in Wine 3.0-rc3, although it makes no sense at all (incorrect encoding?)
No response in two years. Fixed.
https://bugs.winehq.org/show_bug.cgi?id=13355
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #21 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 3.0-rc4.
-
wine-bugs＠winehq.org