Thanks for the additional explanations! On 2024-06-07 15:20, Luuk van der Duim wrote:
What any screen-reader/AT would like is to offer best response times to users by caching objects up-front to minimize IPC round trips between AT and application.For `atspi` we would like to offer a cache for any AT to use. A tree with a subset of data and keep that up-to-date by listening for signals.You are right LibreOffice does not proactively send a 96G array but it does offer `GetChildren` on the public bus which will.
When it comes to the AT-SPI `GetChildren` method, LibreOffice only implements functions to get the child count and to get a child at a given index, calling both of which should be unproblematic performance-wise by themselves (i.e. in particular when not iterating over all children).
If you're using the gtk3 VCL plugin (UI variant), the `GetChildren` implementation is provided by ATK/atk-adaptor (which is now part of the at-spi2-core git repo) and iterates over all of the children, causing the problems you describe.
It means one can never call `GetChildren` on that object because it makes no sense. It makes naively building a tree like the example program [1] does is impossible because LibreOffice Calc wants to return something that in practical terms no-one can handle.(...)In practical sense, if your array of children is huge, please make sure to not exceed D-Bus message limit of 128MB.(...)Could LibreOffice please limit the reply-message to something reasonably sized? (Or at least legally sized?) This is currently a bit of a foot-gun with a public interface.
I've submitted a merge request to at-spi2-core to limit the maximum amount of children to return, similar to what an earlier change did when using the Collection interface:
https://gitlab.gnome.org/GNOME/at-spi2-core/-/merge_requests/159 Does that help?(Of course, this doesn't mean that the way that LibreOffice shouldn't eventually optimize handling of how Calc cells are reported on the a11y level altogether, but as I mentioned, there are still open questions related to that, so that IMHO needs more discussion + effort to implement.)
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
