Re: [libreoffice-accessibility] Re: [a11y] LibreOffice Calc exposes 2^31 children, freezes on `GetChildren`
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: [email protected] 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
Re: [libreoffice-accessibility] Re: [a11y] LibreOffice Calc exposes 2^31 children, freezes on `GetChildren`
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: [email protected] 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
Re: [libreoffice-accessibility] Re: [a11y] LibreOffice Calc exposes 2^31 children, freezes on `GetChildren`
On 14/6/24 17:25, Michael Weghorn wrote: Personal preferences aside, Windows/NVDA as the most widely used platform indeed generally has some priority for me, as does Writer over Calc over everything else. There are other factors I also take into account, though, e.g. involvement/contributions from others like people working in certain areas, user requests/tickets, possibilities to cooperate (e.g. the Orca maintainer reworking Orca's LibreOffice support and providing a lot of helpful feedback and input) or productivity (my productivity on Linux is way higher than on Windows, so my take is that putting some extra initial effort in order to be able to do most of the analysis for issues *also* affecting Windows on Linux usually pays off, in particular since the platform APIs IAccessible/AT-SPI2 are fairly similar). A further consideration is that, unlike Windows users, Linux users don't have the option of running Microsoft Office without setting up virtualization, rebooting the machine to a different environment, or using a different machine for the purpose. Of course, some Windows users might not be able to afford it, and they're also an important group to consider, as are those who prefer the LibreOffice interface. I personally have access to Microsoft Office as well at the moment, but, obviously, not in my Linux environment. I think the problem of disclosing large documents to accessibility APIs is real and important. I suspect this explains the extraordinary performance issue that occurs if you try to open a long document in Microsoft Word for Mac with the VoiceOver screen reader enabled - the application can be completely unresponsive for several minutes, even on a fast machine, while the document loads. 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? My assumption is that once the initial transfer is done, all the remaining updates are incremental, and relatively fast. 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. -- To unsubscribe e-mail to: [email protected] 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
