393902 - can we avoid invalidating the entire tree in nsAutocompleteController::ProcessResult()?

Status: RESOLVED INVALID

(Toolkit :: Autocomplete, defect, P2)

Description

[(not reading, please use [e-mail] instead)]

can we avoid invalidating the entire tree in nsAutocompleteController::ProcessResult()?

spun off from bug #389593 comment #4:

gavin wrote:

Seems like we invalidate the entire tree in ProcessResult(), ideally in the
incremental search case we could invalidate only the rows that were added
(which in most cases won't even be drawn because they're scrolled off the
screen). I think the best way to do this would be to expose additional
invalidate*() variants on nsIAutoCompletePopup, implement them in
autocomplete.xml (which just forwards to the tree's boxobject), and then have
the autocomplete controller invalidate only the parts that have changed. This
might be tricky because the controller can't know how the two sets of results
differ, because the history service nsIAutocompleteSearch impl just calls
onSearchResult multiple times with a new autocomplete result each time, as far
as I can tell, but something to look at in a followup bug, for sure (I think it
would also benefit other autocomplete consumers, and probably fix bug 391889).

Comment 1

[(not reading, please use [e-mail] instead)]

see also dietrich comment at https://bugzilla.mozilla.org/show_bug.cgi?id=389491#c32

Comment 2

[Dietrich Ayala (:dietrich)]

adding tsnap to the whiteboard to get this visible, since it affects our ability to make things appear responsive in a reasonable way.

Comment 3

[Shawn Wilsher :sdwilsh]

Attachment: v0.1

A work in progress.  I am not presently sure how to handle invalidateRow for the richlist popup, which is sadly what the location bar uses.  The other one is super easy to do!

Comment 4

[Shawn Wilsher :sdwilsh]

Attachment: v0.2

I don't even know if this works, but I'm uploading a checkpoint.  I have figured out how to invalidate just a row with the richlistbox implementation.

Comment 5

[Shawn Wilsher :sdwilsh]

I am not actually sure that this is even needed.  The richlistbox autocomplete smartly updates things.  The tree autocomplete doesn't so much though, so it might be needed there.

Comment 6

[Johnathan Nightingale [:johnath]]

This sounds like an opportunistic perf/responsiveness win, so definitely wanted if there's a real win to be had - but not something we'd hold the release for.

Comment 7

[Marco Bonardo [:mak]]

tree autocomplete has gone.