Date: prev next · Thread: first prev next last


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."



--
To unsubscribe e-mail to: accessibility+unsubscribe@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/accessibility/
Privacy Policy: https://www.documentfoundation.org/privacy

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.