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: 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