RichTextCtrl responsiveness

[David]

Hi all,

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 use wxPython, but Robin Dunn has suggested I bring this
issue over here, as he feels it is wxWidgets-related rather than
wxPython-related.)

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 fully editable.

My current theory is that something changed in wxWidgets between 2.8.12.0
and 2.9.4.0 that is causing this slowdown.

So ... can anyone confirm this problems with wxWidgets, independent of
wxPython? Is a bug report warranted?

Any suggestions for a quick fix or work-around?

Thanks,
David
http://www.transana.org

[Julian Smart]

Hi David,

The short answer is to call:

wxRichTextBuffer::SetFloatingLayoutMode(false);

At least I hope this fixes it for you.

The problem is that usually wxRTC optimizes layout such that as it works
down the buffer laying out objects, once it sees that the layout hasn't
changed (e.g. for a keystroke) it doesn't have continue laying out to
the bottom of the document - it just increments the positions of the
following paragraphs.

Unfortunately if trying to lay out floating objects, which could impinge
on layout almost anywhere in the buffer, it's not so clear how to
optimize layout, so it doesn't. That needs some concerted work so
performance is reasonable.

Regards,

Julian

Post by David
Hi all,
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 use wxPython, but Robin Dunn has suggested I bring
this issue over here, as he feels it is wxWidgets-related rather than
wxPython-related.)
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 fully editable.
My current theory is that something changed in wxWidgets between
2.8.12.0 and 2.9.4.0 that is causing this slowdown.
So ... can anyone confirm this problems with wxWidgets, independent of
wxPython? Is a bug report warranted?
Any suggestions for a quick fix or work-around?
Thanks,
David
http://www.transana.org
--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
or visit http://groups.google.com/group/wx-users

[Julian Smart]

Hi David,

I have committed a fix to wxWidgets SVN head (3.1) so that wxRTC no
longer lays out the whole buffer in floating object layout mode. You can
test it with the sample (sorry, the C++ one) by adding large amounts of
text and then editing at the top of the buffer. Only 3.5 years after
floating objects were first implemented, but better late than never.

The optimization adds a variable to wxRichTextParagraph and further
arguments to a couple of functions so unfortunately can't be
straightforwardly backported to 3.0. But if one was ingenious, one might
be able to use wxRTC object properties and global variables to
accomplish it. Meanwhile the
wxRichTextBuffer::SetFloatingLayoutMode(false) fix should still work if
you don't need to display floating objects as actually floating.

Regards,

Julian

Post by Julian Smart
Hi David,
wxRichTextBuffer::SetFloatingLayoutMode(false);
At least I hope this fixes it for you.
The problem is that usually wxRTC optimizes layout such that as it
works down the buffer laying out objects, once it sees that the layout
hasn't changed (e.g. for a keystroke) it doesn't have continue laying
out to the bottom of the document - it just increments the positions
of the following paragraphs.
Unfortunately if trying to lay out floating objects, which could
impinge on layout almost anywhere in the buffer, it's not so clear how
to optimize layout, so it doesn't. That needs some concerted work so
performance is reasonable.
Regards,
Julian

Post by David
Hi all,
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 use wxPython, but Robin Dunn has suggested I
bring this issue over here, as he feels it is wxWidgets-related
rather than wxPython-related.)
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 fully editable.
My current theory is that something changed in wxWidgets between
2.8.12.0 and 2.9.4.0 that is causing this slowdown.
So ... can anyone confirm this problems with wxWidgets, independent
of wxPython? Is a bug report warranted?
Any suggestions for a quick fix or work-around?
Thanks,
David
http://www.transana.org
--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
or visit http://groups.google.com/group/wx-users

[David Woods]

Hi Julian,

Thank you for your attention to this.

I can confirm the following about the C++ RichText sample program:

wxWidgets 2.8.12 did not show any slowdown with large RichText documents.

wxWidgets 3.0.0 showed significant slowdown at the beginning of a 7000 line
document. Characters were taking about 4 seconds or so to appear.

Adding wxRichTextBuffer::SetFloatingLayoutMode(false) solved the problem
with my 7000 line document.

wxWidgets 3.1.0, taken from SVN today, also solves the slowdown problem
with my 7000 line document. I did not go into the sample code to add the
wxRichTextBuffer::SetFloatingLayoutMode(false) line, as it was not
necessary.

So not surprisingly, everything you said and did was perfect.

Thanks again,

David

Post by Julian Smart
Hi David,
I have committed a fix to wxWidgets SVN head (3.1) so that wxRTC no longer
lays out the whole buffer in floating object layout mode. You can test it
with the sample (sorry, the C++ one) by adding large amounts of text and
then editing at the top of the buffer. Only 3.5 years after floating
objects were first implemented, but better late than never.
The optimization adds a variable to wxRichTextParagraph and further
arguments to a couple of functions so unfortunately can't be
straightforwardly backported to 3.0. But if one was ingenious, one might be
able to use wxRTC object properties and global variables to accomplish it.
Meanwhile the wxRichTextBuffer::SetFloatingLayoutMode(false) fix should
still work if you don't need to display floating objects as actually
floating.
Regards,
Julian

Post by Julian Smart
Hi David,
wxRichTextBuffer::SetFloatingLayoutMode(false);
At least I hope this fixes it for you.
The problem is that usually wxRTC optimizes layout such that as it works
down the buffer laying out objects, once it sees that the layout hasn't
changed (e.g. for a keystroke) it doesn't have continue laying out to the
bottom of the document - it just increments the positions of the following
paragraphs.
Unfortunately if trying to lay out floating objects, which could impinge
on layout almost anywhere in the buffer, it's not so clear how to optimize
layout, so it doesn't. That needs some concerted work so performance is
reasonable.
Regards,
Julian

Post by David
Hi all,
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 use wxPython, but Robin Dunn has suggested I bring this
issue over here, as he feels it is wxWidgets-related rather than
wxPython-related.)
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 fully editable.
My current theory is that something changed in wxWidgets between
2.8.12.0 and 2.9.4.0 that is causing this slowdown.
So ... can anyone confirm this problems with wxWidgets, independent of
wxPython? Is a bug report warranted?
Any suggestions for a quick fix or work-around?
Thanks,
David
http://www.transana.org
--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
or visit http://groups.google.com/group/wx-users

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
or visit http://groups.google.com/group/wx-users