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.