Feature #133
closed
Optimize the OutputWindow
Description
So far, whenever CocoMUD receives a new output from the server, it updates its ENTIRE window, which means freezing the output, clearing it all, replacing with a fresh output and placing the cursor back where it was before thawing. This has some issues, not least begin an accessibility issue in Linux. Furthermore, CocoMUD could be much, much faster if it only appended to the window without replacing everything.
- Sprint/Milestone set to 16
- Status changed from Open to In Progress
- % Done changed from 0 to 20
Starting from commit db3467ab9c2d1778bcbf977127890baf22ca62f2, CocoMUD doesn't update its entire window, though it still uses ChangeValue giving it the entire text of the window. I was unable to find some practical solution, although we could, in theory, append only the text without modifying old output, there is apparently no way in wxPython to append text without moving the cursor. This means that the cursor needs to be moved back afterward. The change of the cursor position forces screen readers to update and break accessibility mostly for Braille users (with Jaws in Windows, or with Orca in Linux, NVDA is able to handle this situation without problem).
To quickly explain the situation, it goes like this:
- The user begins to read with the Braille display the window content. By now, the cursor isn't tight to the Braille display position, the Braille display can navigate on other lines without the cursor moving at all.
- CocoMUD receives new text to display. It freezes the window and update its content.
- To do it CocoMUD has to update the windows' text and place the cursor back where it was before the text was added.
- At this point, the screen reader realizes the cursor has moved. The fact that it's exactly on the same line of text it was before isn't handled by most screen readers: NVDA is smart enough to realize that the line of text is exactly the same and doesn't bring the Braille display back. Jaws and Orca (among others) will bring the Braille display back to the cursor position no matter what. It means that a user reading with a Braille display will often see the Braille window shift back to the cursor position.
I didn't know about these problems.
Unfortunately I cann't test it because I don't have a braille display nor a JAWS installation.
Do you know a way to emulate a braille display?
I don't really know how it could work. But from what I'm reading on wxPython, it seems there's no easy solution to that problem anyway. Best case scenario: it's a bug individual screen readers will have to fix. I had wanted to implement a beautiful solution but all the methods on wx.TextCtrl that change contents also play with the cursor. I would really appreciate other accessible alternatives to wxPython, and it's not the first time I think about it. But I'm willing to admit on Windows this is the best I've seen for accessibility.
- Sprint/Milestone deleted (
16)
Again, shifting it back to no given version, it's a tricky issue.
Hi again,
Then the Append function of the TextCtrl control still changes the entire value of the output?
Cheers,
That is correct. Your strategy may be more optimized in the end, perhaps wxWdigets realize most of the text you wish to change is the same. For some unknown reason, I wasn't able to find a method that didn't change the cursor position (the cursor goes either at the beginning of the end). So I don't see an immediate solution to this problem. We'll let this issue open but Sprint 16 won't include it anymore, there are still open issues to close before Saturday!
Just a thought however. I wanted to find something that didn't move cursor position. Well, it's not possible. But I guess we could take advantage of it...
What we do right now, basically, is to clear the window each time new input is received. This is probably costly and players have reported lags when the window becomes too big (hence the option to erase the output window content as a temporary solution). Instead, I suggest that we only append the text to the bottom of the window. This would require to:
- Move to the end of the window (that is, the editing position).
- Save the text between the editing position and the end of the window (the user could have written something).
- Use
AppendText to only append the text that has been received.
- Move the cursor back where it was, since the position is still valid. If the cursor was beyond the editing position, a little calculation will be necessary to determine the new cursor position.
This simple solution was disregarded because it forces the cursor position to update with no compromise. But since the cursor position will change no matter what, why bother?
A note here: it might be very efficient for the window without rich-text. But for a rich-text, an additional concern arises: when using AppendText, is the style preserved? If so, we could really optimize both windows.
- Sprint/Milestone set to 17
The idea described in previous comments has been tested successfully on the Blind User Interface (see in particular specific/wx4/text.py ). The idea is to identify the point where current and future text varies and to only remove the part that's not needed, adding the part that is new. This way, updating the entire screen is not necessary for CocoMUD. This, however, will need to be thoroughly tested with Text-Rich enabled.
- Status changed from In Progress to Closed
- % Done changed from 20 to 100
Tested the new solution, but there's not much to implement. I cannot do anything more about performances in regard to the output window. This is a disappointment, as some users still complain about CocoMUD's sluggishness after a few hours of play and have to clear the output window. I'm afraid we'll have to learn to live with it.
Please register to edit this issue
Also available in: Atom
PDF
Tracking page
.