Closed Bug 76164 Opened 24 years ago Closed 23 years ago

modifying/moving a filter causes several seconds of flashing/redrawing if there are many filters above it

Categories

(MailNews Core :: Filters, defect)

Product:
MailNews Core
Component:
Filters
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME
Milestone:
mozilla1.2beta

People

(Reporter: Bienvenu, Assigned: sspitzer)

References

Details

(Keywords: perf, Whiteboard: [Hixie-P0][Hixie-1.0])

If I click on the enable/disable column in the filter picker dialog, the list box flashes and scrolls up and down for several seconds - it's very painful.
I'm not seeing this using win98 with feb16 commercial trunk build.
QA Contact: esther → laurel
how about the April 16th build? :-) Do you have enough filters to have a scroll bar?
I'm not sure why I was thinking February?! I'm really using today's (apr16) build. Yes, I've got a scroll bar and I still don't see a flashing at all. Modern theme.
David, I don't see this on the 4/22 build on Win 2000 either. I have a scrollbar as well. Are you still seeing this?
sorry, this only happens when I have to scroll down to the bottom of the filter list to get to the filter I want to enable/disable. Did you try that?
Yeah. It makes it scroll to the top for me but it happens pretty quickly for me. I don't have that many filters so perhaps with a lot of filters and a slower machine this action takes a few second. I agree that it shouldn't do this.
IIRC, your home machine is a bat out of hell :-) I have about 20 filters, and a P 450.
Well, I only have about 6 filters so I had to make my window small to get the scrollbar. Perhaps that had to do with it. I'm also using a release build (assuming you're using a debug build).
Blocks: 77248
I have > 25 filters. Changing _anything_ on a filter (enable/disable, edit, move ...) at the bottom of the list causes lots of repainting for me. I'm unsing 2001051720 Win2k installer on a AMD K6-II+ 500. Maybe the algorithm is to blaim: It looks like the list is rebuild and completely repainted + scrolled for each existing line above the modified filter. Strangely, the scrollbar is _growing_ during the process! After all the repainting, the scrollbar regains its normal size. Adding perf keyword, nominating for 0.9.2 and changing summary from "clicking the enable/disable column in filter dialog causes several seconds of flashing/redrawing" to "modifying a filter causes several seconds of flashing/redrawing if there are many filters above it".
Keywords: mozilla0.9.2, perf
Summary: clicking the enable/disable column in filter dialog causes several seconds of flashing/redrawing → modifying a filter causes several seconds of flashing/redrawing if there are many filters above it
Hey, I'm not the only crazy one! :-)
reassigning to naving
Assignee: gayatrib → naving
Also occures on NetBSD/PPC + XFree86 4.0.1 with mozilla 0.9 and 0.9.1 (and earlier mozilla releases if I remember correctly).
-->OS=All
OS: Windows 2000 → All
Summary: modifying a filter causes several seconds of flashing/redrawing if there are many filters above it → modifying/moving a filter causes several seconds of flashing/redrawing if there are many filters above it
*** Bug 88213 has been marked as a duplicate of this bug. ***
I investigated some, and this is plain weird. I suspect (although it would surprise me if I was right :) ) that the whole refresh routine for this dialog's tree is a hack. Basically the refresh routine, refreshFilterList, does this to refresh the tree: 1. Clears the current selection 2. Re-selects the item 3. Makes sure the item is visible This may sound simple, but obviously it's causing the whole tree to repaint. Hence the reason I think this is some sort of hack to force a refresh. If I remove the function, clicking on a cycling column (for example to toggle enabled/disabled state of a filter) doesn't display. Do other trees do this? I know that those that are using RDF doesn't have to mess around with repainting "by hand" like this. I wanna fix this. Seth, any advice?
Blocks: advocacybugs
Keywords: mozilla0.9.4, mozilla1.0
*** Bug 93966 has been marked as a duplicate of this bug. ***
Hardware: PC → All
Blocks: patchmaker
Converting <tree> to <outliner> may fix this bug. Bug 73948
This is one of the most painful problems in Mail right now.
Keywords: polish
Whiteboard: [Hixie-P0][Hixie-1.0]
No longer blocks: patchmaker
Not a polish bug (way too complex to fit that criteria).
Keywords: polish
Blocks: 91351
*** Bug 130563 has been marked as a duplicate of this bug. ***
taking, because I think I fixed this with some code cleanup. david, can you try again?
Assignee: naving → sspitzer
Target Milestone: --- → mozilla1.2beta
Just out of curiosity: Which cleanup fixed this?
Marking worksforme... using current trunk builds.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
verified worksforme in current trunk.
Status: RESOLVED → VERIFIED
great, this works for me now too.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.