[libreoffice-accessibility] Re: [a11y] LibreOffice Calc exposes 2^31 children, freezes on `GetChildren`

[Michael Weghorn]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20240619/e8133ac9/attachment.sig>