Skip to content

Gecko vbufBackend: If a table row is invalidated, it should not require its parent to be updated#8833

Merged
michaelDCurran merged 2 commits into
masterfrom
vbufPartialRenderRowFix
Oct 10, 2018
Merged

Gecko vbufBackend: If a table row is invalidated, it should not require its parent to be updated#8833
michaelDCurran merged 2 commits into
masterfrom
vbufPartialRenderRowFix

Conversation

@michaelDCurran

Copy link
Copy Markdown
Member

Link to issue number:

None.

Summary of the issue:

The work to speed up dynamic updates in virtualBuffers in pr #8678 causes a major slowdown in the new Gmail interface.
Specifically:
When arrowing up and down the message list, a cell on one of the rows is changed in such a way that in Gecko its accessible is re-framed and therefore the row itself is marked in the virtualBuffer as being invalid. But as row nodes in the Gecko vbufBackend have their requiresParentUpdate property set to true, this causes the entire table to be re-rendered.
The comment where this property is set specifically talks about row groups needing this, not rows. But the code does not correctly exclude rows.
As we know that other row coordinates will not change just because a row was invalidated, it would be safe to exclude rows from having their requiresParentUpdate property set to true.

Description of how this pull request fixes the issue:

This PR only sets requiresParentUpdate to true on nodes within tables that are not cells or rows. (In otherwords, probably just row groups).

Testing performed:

  • In New gmail, arrowed up and down an inbox. The lag no longer exists.
  • Tested German wikipedia page: No change in performance.
  • Tested inserting rows at the top of a table: row coordinates for the entire table stayed correct.

Known issues with pull request:

None.

Change log entry:

None.

…re its parent to be updated. this is not logically needed, and caused a major performance hit on gmail.
@michaelDCurran michaelDCurran requested a review from jcsteh October 9, 2018 23:19

@jcsteh jcsteh left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

// Thus, ensuring we rerender this node's parent, gives a chance to rerender other table rows.
LOG_DEBUG(L"Setting node's requiresParentUpdate to true");
parentNode->requiresParentUpdate=true;
// Note that we however do not want to set this on table rows as if this row alone is invalidated, none of the other row coodinates would be affected.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo: coodinates -> coordinates

@michaelDCurran michaelDCurran merged commit 526d6fc into master Oct 10, 2018
@nvaccessAuto nvaccessAuto added this to the 2018.4 milestone Oct 10, 2018
@LeonarddeR

LeonarddeR commented Oct 16, 2018

Copy link
Copy Markdown
Collaborator

Last week, I was playing with a pretty complex corporate web application, which unfortunately isn't public. This application had a table that changed as soon as you selected some criteria and pressed a search button. However, the changes in the table weren't reflected in browse mode, I had to refresh the virtual buffer in order for the new cells to show up. Table navigation was broken as well. This wasn't a problem with NVDA 2018.3.2.

Unfortunately, I don't know of a way to reproduce this. Creating a simple html table with a button beneath it that magically adds a row or a cell within a row works correctly (i.e. it does not trigger this behavior).

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants