The default bug view has changed. See this FAQ.

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

NEW
Unassigned

Status

()

Toolkit
Autocomplete
P2
normal
10 years ago
2 years ago

People

(Reporter: (not reading, please use seth@sspitzer.org instead), Unassigned)

Tracking

({perf})

Trunk
Points:
---
Bug Flags:
blocking1.9.2 -
wanted1.9.2 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Snappy:P2], URL)

Attachments

(1 attachment, 1 obsolete attachment)

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).
see also dietrich comment at https://bugzilla.mozilla.org/show_bug.cgi?id=389491#c32

Updated

8 years ago
Blocks: 455555
Flags: blocking1.9.2?
Keywords: perf
adding tsnap to the whiteboard to get this visible, since it affects our ability to make things appear responsive in a reasonable way.
Priority: -- → P2
Whiteboard: [tsnap]
Created attachment 388092 [details] [diff] [review]
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!
Assignee: nobody → sdwilsh
Status: NEW → ASSIGNED

Updated

8 years ago
Attachment #388092 - Attachment is patch: true
Attachment #388092 - Attachment mime type: application/octet-stream → text/plain
Created attachment 388375 [details] [diff] [review]
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.
Attachment #388092 - Attachment is obsolete: true
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.
Assignee: sdwilsh → nobody
No longer blocks: 455555
Status: ASSIGNED → NEW
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.
Flags: wanted1.9.2+
Flags: blocking1.9.2?
Flags: blocking1.9.2-
Whiteboard: [tsnap] → [snappy]

Updated

5 years ago
Whiteboard: [snappy] → [Snappy:P2]
You need to log in before you can comment on or make changes to this bug.