On 2024-06-15 20:31, Michael Weghorn wrote:
On 2024-06-15 14:55, Jason J.G. White wrote:My limited understanding of the new protocol proposed for Linux by the GNOME Foundation is that it is expected to use pipes for data transfer, giving better performance than DBus calls. So my naive question is: what would be the performance cost of transferring a large document over the proposed API? Could it be partly done in the background, so that the user can at least start to read/edit the document from the top while the data structures are built and sent to the screen reader?To my knowledge, the new protocol is still in development stage, and handling of large documents was earlier explicitly mentioned as something that will still need further consideration.I also haven't received any feedback to my ticket concerning that topic so far, see [1].(...)[1] https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/142
FYI, Matt Campbell (the developer working on Newton) published a blog post about the current status:
https://blogs.gnome.org/a11y/2024/06/18/update-on-newton-the-wayland-native-accessibility-project/ It has this about large documents:"The biggest unresolved issue at this point is whether the push-based approach of Newton, the motivation for which I described in the previous post, will have unsolvable drawbacks, e.g. for large text documents. The current AccessKit implementation for GtkTextView pushes the full content of the document, with complete text layout information. On my brand new desktop computer, this has good performance even when reading an 800 KB ebook, but of course, there are bigger documents, and that’s a very fast computer. We will likely want to explore ways of incrementally pushing parts of the document based on what’s visible, adding and removing paragraphs as they go in and out of view. The challenge is to do this without breaking screen reader functionality that people have come to depend on, such as Orca’s Say All command. My best idea about how to handle this didn’t occur to me until after I had finished the current implementation. Anyway, we should start testing the current, naive implementation and see how far it takes us."
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
