Closed Bug 285002 Opened 16 years ago Closed 15 years ago
slow scrolling/redrawing in new cookies window with many cookies
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.
Component: Extension/Theme Manager → Preferences
Summary: slow scrolling/redrawing in new cookies window with many cookies → slow scrolling/redrawing in new cookies window with many cookies
_very_ slow here as well. Would be really nice if this could be sped up a bit.
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.
*** Bug 285075 has been marked as a duplicate of this bug. ***
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?
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.
(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
Really slow. Asking for blocking 1.1.
OS: Windows 2000 → Windows XP
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
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.
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.
Flags: blocking-aviary1.1? → blocking-aviary1.1-
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.
Nominating to put on radar again
Flags: blocking-aviary1.1- → blocking-aviary1.1?
nominating for b4 too.
15 years ago
Flags: blocking-aviary1.1? → blocking-aviary1.1+
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.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.