Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid rendering braille regions for common context upon a focus change #201

nvaccessAuto opened this issue Jan 1, 2010 · 3 comments


Copy link

Reported by jteh on 2008-10-23 16:18
Currently, when a focus change occurs, NVDA clears the braille buffer and renders braille regions for the entire focus context; i.e. selected focus ancestry. If there is a lot of focus ancestry, this can be quite slow, especially as rendering a region for an NVDAObject accesses many properties. There is no need to re-render regions for common context, as update events should have kept these up to date. Only braille regions for new objects need be rendered. This will dramatically speed up handling of focus changes, which are currently considerably slow in certain cases.

Copy link

Comment 1 by jteh on 2008-10-23 17:12

  • I'm not sure how best to achieve this:
    1. We could use the focus difference level.
    2. This would obviously be relatively efficient.
    3. However, the context regions may skip some objects, so it is not as simple as truncating regions up to the focus difference level and rendering regions for the ancestry after that point.
    4. This is very specific to focus and would not be useable for context in any other case.
    5. This said, we don't currently use context for anything else anyway. Initially, I thought review might show context, but Mick and I agreed that this isn't really necessary or useful for review.
    6. getContextRegions() should probably be rewritten to do all of this and thus avoid unnecessary scanning and checks.
    7. Alternatively, we could generate the regions as we do now, find the last common region by comparing the objects and render from that point. getContextRegions() doesn't actually call update() to render the regions; it just constructs the region object.
    8. However, it does interrogate the object, checking its properties to determine whether it should be included in the context. This is less expensive than rendering the region, but it would still be more optimal to avoid it.

Copy link

Comment 2 by jteh on 2008-11-11 05:28

  • We don't need context for review, so making context specific to focus is fine. This allows for much greater optimisation.
  • Mick suggested that we store the index into focus ancestors on each region. When the focus changes, we can then find the region with an index which is closest to (<=) the focus difference level.
    • This eliminates the need for empty placeholder regions for skipped focus ancestors.
  • Using focus ancestors allows us to simply scan forward through the focus ancestors list.

Copy link

Comment 4 by jteh on 2008-11-20 04:43
Implemented in r2517.
State: closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

2 participants