Optimize the OutputWindow
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.
#2 Updated by Vincent Le Goff about 1 year ago
- 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.
#4 Updated by Vincent Le Goff about 1 year ago
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.
#7 Updated by Vincent Le Goff 12 months ago
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!
#8 Updated by Vincent Le Goff 12 months ago
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).
AppendTextto 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.
Please register to edit this issue