285002 - slow scrolling/redrawing in new cookies window with many cookies

Status: RESOLVED FIXED

(Firefox :: Settings UI, defect)

Description

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050306
Firefox/1.0+

Tools > Options > Privacy > Cookies > View Cookies

I probably have about 400-500 cookies in my list. When viewing the cookies in
the cookie list, if I use the side scrollbar to pull the list up and down, it
updates/redraws  very slow.

Once it has settled down it seems using the side scrollbar to scroll up and down
quickly around the local vicinity is ok, but if I choose to jump the scrollbar
to a new area of the cookie list it again updates/redraws very slowly.

Comment 1

[Josh Powell]

_very_ slow here as well. Would be really nice if this could be sped up a bit.

Comment 2

[Steve England [:stevee]]

Just to add that with the same cookies.txt and the old pref window, scrolling
through the cookies list is fast & responsive. When scrolling through the same
cookies.txt with the new pref window, scrolling can be slow and unresponsive.

With small lists of cookies scrolling in both versions of the prefs window is
fast and responsive, so you really do need a lot of cookies (100s) to see this
issue.

Comment 3

[PikeUK]

*** Bug 285075 has been marked as a duplicate of this bug. ***

Comment 4

[Radek 'sysKin' Czyz]

The lower in the list of cookies I am, the slower it all works. Is the list
redrawing/processing every entry from top to the place I'm currently seeing?

Comment 5

[Bill Gianopoulos [:WG9s]]

It seems to me as if the problem has to do with the tree type view.  I appears
that it takes to scroll past each collapsed container is dependent on how many
items are in the container.

Comment 6

[Josh Powell]

(In reply to comment #5)
> It seems to me as if the problem has to do with the tree type view.  I appears
> that it takes to scroll past each collapsed container is dependent on how many
> items are in the container.

Yes, it is (I think) when you type in a search, and the cookies are displayed in
a non-tree view, they scroll fast, like they used to.


Josh

Comment 7

[Nickolay_Ponomarev]

Really slow. Asking for blocking 1.1.

Comment 8

[Nickolay_Ponomarev]

Attachment: Venkman profile info

I opened the cookies window scrolled to the bottom and scrolled up and down a
few times.

As one would expect, the most slow functions are in the object that implements
treeview, and all slowness is because _getItemAtIndex implementation is quite
slow, going through the whole array of hosts for the items that are in the very
end.

 function name		calls	total time
--------------------------------------------
 _view._getItemAtIndex	6033	33406.25
 _view.isContainer	2199	12406.25
 _view.isContainerOpen	1666	9109.38
 _view.getCellText	1099	6546.88

Comment 9

[Nickolay_Ponomarev]

Could probably be fixed by using code like in bug 240884 comment 0.

Or we could approximate the indices of first and last visible host by storing
indices of first/last visible rows (from treeboxobject) and if they are
modified, do something like
firstVisibleHostIndexApprox = firstVisibleHostIndex + firstVisibleRowNew -
firstVisibleRowOld;
(also need to update firstVisibleHostIndexApprox on collapsing/expanding of the
host)

That way the following inequality will be held
firstVisibleHostIndexApprox <= firstVisibleHostIndex < lastVisibleHostIndex <=
lastVisibleHostIndexApprox.

Improved performance will be achieved because _getItemAtIndex would first loop
from firstVisibleHostIndexApprox to lastVisibleHostIndexApprox, meaning that all
calls to TreeView methods will take time proportionate to the height of the window.

I'm not volunteering to write this though.

Comment 10

[Mike Connor [:mconnor]]

We can ship with this, easy workaround is to just search instead of scrolling
(which is faster UI-wise too).  If a safe and well-reasoned patch appears,
great, but we're not going to hold for this.

Comment 11

[Andrzej Kaczmarek]

Attachment: proposed patch

Idea: for each item index processed in _getItemIndexAt we can store indexes of
host element closest to given index. Next time we want some item, we get stored
indexes of host element placed as close as possible to given index and start
searching from this element instead of beginning. Also every tree modification
causes invalidation of stored indexes starting from place where modification
was made.
I know this definitely isn't perfect solution, but it works weel (at least for
me ;) and speeds up scrolling *very* significantly.

Comment 12

[Victor Luchits]

Nominating to put on radar again

Comment 13

[Nickolay_Ponomarev]

nominating for b4 too.

Comment 14

[Mike Connor [:mconnor]]

Comment on attachment 189500 [details] [diff] [review]
proposed patch

I don't know if there's a good fix that's worth the effort, but this makes this
a lot better, so let's take this.