In my app, some people edit very, very large documents. Over the last couple of years, I’ve developed a reasonable RTF editor based on wxRichTextCtrl.
I have a sample document from a user, 122 pages long, just under 40,000 words, just over 225,000 characters, and everything works well enough in wxPython 2.8.12.0. Editing is quite responsive throughout the document. (This is while using the wxRichTextCtrl Demo program, so I know it’s not related to my code.)
But with wxPython 2.9.4.0 and 3.0.0.0, the wxRichTextCtrl has become basically unusable for large documents. When editing near the beginning of a large document, processing each key stroke can take a painful 1 to 2+ seconds. (Still in the wxPython wxRichTextCtrl Demo.)
I’m seeing this problem on both Windows (2.9.4.0 and 3.0.0.0) and OS X (2.9.4.0, haven’t actually tested 3.0.0.0.) The slowdown seems to fall between the end of the EVT_CHAR event and the beginning of the EVT_KEY_UP event. The further into the document you are, the less a problem it is, and the end of the document is perfectly well editable.
Is it possible this is a wxPython issue, or do I need to report this to wxWidgets? Any ideas what I can do in the interim for my users, who need to be able to edit their very large documents? I can’t go back to wxPython 2.8.12.1 due to other bugs in the wxRichTextCtrl that upgrading has solved.
In my app, some people edit very, very large documents. Over the last
couple of years, I've developed a reasonable RTF editor based on
wxRichTextCtrl.
I have a sample document from a user, 122 pages long, just under 40,000
words, just over 225,000 characters, and everything works well enough in
wxPython 2.8.12.0. Editing is quite responsive throughout the
document. (This is while using the wxRichTextCtrl Demo program, so I
*know* it's not related to my code.)
But with wxPython 2.9.4.0 and 3.0.0.0, the wxRichTextCtrl has become
basically unusable for large documents. When editing near the beginning
of a large document, processing each key stroke can take a painful 1 to
2+ seconds. (Still in the wxPython wxRichTextCtrl Demo.)
I'm seeing this problem on both Windows (2.9.4.0 and 3.0.0.0) and OS X
(2.9.4.0, haven't actually tested 3.0.0.0.) The slowdown seems to fall
between the end of the EVT_CHAR event and the beginning of the
EVT_KEY_UP event. The further into the document you are, the less a
problem it is, and the end of the document is perfectly well editable.
Is it possible this is a wxPython issue, or do I need to report this to
wxWidgets? Any ideas what I can do in the interim for my users, who
need to be able to edit their very large documents? I can't go back to
wxPython 2.8.12.1 due to other bugs in the wxRichTextCtrl that upgrading
has solved.
I can't think of anything that would be wxPython specific that would cause something like this, so you should raise this issue with the wxWidgets group.
In my app, some people edit very, very large documents. Over the last
couple of years, I’ve developed a reasonable RTF editor based on
wxRichTextCtrl.
I have a sample document from a user, 122 pages long, just under 40,000
words, just over 225,000 characters, and everything works well enough in
wxPython 2.8.12.0. Editing is quite responsive throughout the
document. (This is while using the wxRichTextCtrl Demo program, so I
know it’s not related to my code.)
But with wxPython 2.9.4.0 and 3.0.0.0, the wxRichTextCtrl has become
basically unusable for large documents. When editing near the beginning
of a large document, processing each key stroke can take a painful 1 to
2+ seconds. (Still in the wxPython wxRichTextCtrl Demo.)
I’m seeing this problem on both Windows (2.9.4.0 and 3.0.0.0) and OS X
(2.9.4.0, haven’t actually tested 3.0.0.0.) The slowdown seems to fall
between the end of the EVT_CHAR event and the beginning of the
EVT_KEY_UP event. The further into the document you are, the less a
problem it is, and the end of the document is perfectly well editable.
Is it possible this is a wxPython issue, or do I need to report this to
wxWidgets? Any ideas what I can do in the interim for my users, who
need to be able to edit their very large documents? I can’t go back to
wxPython 2.8.12.1 due to other bugs in the wxRichTextCtrl that upgrading
has solved.
I can’t think of anything that would be wxPython specific that would cause something like this, so you should raise this issue with the wxWidgets group.
Unfortunately, I don't think that method is exposed in wxPython, at
least not where I can find it. Any suggestions?
I'll get that method added (and its corresponding Get) for the next 3.0.1 preview build, which will probably be happening soon if I'm not too swamped with work tasks.
Thank you so much, Robin. I really appreciate your attention to such details.
I’ve made progress building a control that loads only part of a long transcript for editing, but as you can imagine, it is slower than I’d like around adding more text when needed. So hopefully this method will solve the problem.
···
On Sat, Feb 15, 2014 at 7:27 PM, Robin Dunn robin@alldunn.com wrote:
David Woods wrote:
Robin,
I posted on wxUsers and Julian replied:
The short answer is to call:
wxRichTextBuffer::SetFloatingLayoutMode(false);
At least I hope this fixes it for you.
Unfortunately, I don’t think that method is exposed in wxPython, at
least not where I can find it. Any suggestions?
I’ll get that method added (and its corresponding Get) for the next 3.0.1 preview build, which will probably be happening soon if I’m not too swamped with work tasks.