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].
Other users may disagree, of course, but from my perspective, having the application hang while loading a large document would be unacceptable. However, having to wait a little if I first load a large document, then jump to the end of it (in the worst-case scenario) would be more acceptable. Obviously, loading a large document and then immediately retrieving a list of headings, links etc., is another scenario that would be subject to potential performance issues. It probably depends on what the over-all delays are.
I agree that any solution to expose the document content on the accessibility layer shouldn't cause LibreOffice to become unresponsive for a significant amount of time when opening a document.
[1] https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/142 -- 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