RFC: multi-tree adapter #641
Conversation
Co-authored-by: Luke Warlow <lwarlow@igalia.com>
Co-authored-by: Luke Warlow <lwarlow@igalia.com>
Co-authored-by: Luke Warlow <lwarlow@igalia.com>
we were apparently misusing the term in some places to mean a subtree that did not include the root (now called a child subtree). <https://en.wikipedia.org/w/index.php?title=Glossary_of_graph_theory&oldid=1298088796#S> Co-authored-by: Luke Warlow <lwarlow@igalia.com>
Co-authored-by: Luke Warlow <lwarlow@igalia.com>
Co-authored-by: Luke Warlow <lwarlow@igalia.com>
Co-authored-by: Luke Warlow <lwarlow@igalia.com>
|
as part of our work on adding accessibility support to Servo, we need a way to combine Servo’s accessibility tree with that of the embedding app, and ideally, combine accessibility trees for webviews and iframes within Servo (#604). so far, we think the main concrete problem that needs to be solved when combining accessibility trees is ensuring that node ids are globally unique. we think we can do this by making a “meta-adapter” that rewrites tree updates and action requests from the various subtrees, replacing local node ids with globally unique ids. the meta-adapter would know about the subtrees, where they meet, and which subtree each tree update came from. in exchange, it would expose an Adapter interface for each subtree, bound to that subtree (not yet implemented). internally it would own some concrete Adapter (currently winit in this patch). this patch is a proof of concept, with only basic rewriting of node ids in tree updates. it does not rewrite action requests yet, nor does it correctly rewrite root node and focused node updates. (cc @lukewarlow, @alice, @Loirooriol) |
|
Thanks @delan and the whole team! One major issue I can think of with this approach is that each adapter currently have a very different API, so I don't think we could have this meta adapter be "generic" over an inner adapter, at least not in a simple way. I am also unclear on the performance cost of having to go through this mapping table all the time. |
|
I am working on a different approach to solve this. It is almost complete and I hope I can share something with you soon. Thanks for your patience. |
|
I've been looking into a slightly different version of the approach in this PR where the mapping logic stays the same but it's integrated into the existing adapters rather than being a wrapper. Which should fix the issue regarding the API shapes all being different. Assuming it works out we can push that up and then compare? |
Tests are currently commented out due to wanting access to the winit types.
The activation wrapper is currently a stub. Action handler is reverse mapping from the global ids back to local ids.
Exploring a deeper integration of multitree to work around API differences per platform adapter
This way we only run the extra code when its been opted into.
Co-authored-by: Alice Boxhall <alice@igalia.com>
- Removes plugin - Also fix subtree registration Co-authored-by: delan azabani <dazabani@igalia.com>
Co-authored-by: delan azabani <dazabani@igalia.com>
|
@DataTriny thanks for proposing the changes in #655! in the meantime, we’ve pushed our reworked approach to this patch as e89abf40c1873...1679fcf06eac2. as @lukewarlow said, it pushes the logic down from a wrapper adapter to the existing adapters (winit only for now). while this seems to be a possible approach, we haven’t had a chance to measure the performance with non-trivial trees, and it looks like implementing garbage collection (not present in our original patch) would require us to retain a copy of all parent-child references (implemented), plus a copy of the full contents of all nodes that host a subtree (not implemented). since the consumer crate already has all of that information, we expect that your approach will make more sense. |
3 participants
No description provided.