Closed Bug 7524 Opened 26 years ago Closed 25 years ago

Slow performance when there's an image in the Messenger thread pane

Categories

(Core :: Graphics: ImageLib, defect, P3)

defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: scottputterman, Assigned: pnunn)

References

()

Details

(Whiteboard: [Perf])

Please see the message "More profiling results for displaying headers in the Messenger thread pane" which I posted on 5/26/99 in mozilla.public.performance, mozilla.public.mail-news, and mozilla.public.layout. If I'm lucky, the above url will work as well. Basically I found that when I remove the image that goes next to the subject in the Messenger 3 pane, it takes 1/4 of the time to load a folder. The Quantify results provided in the message seem to agree with this. Having that image there is an important part of our UI, but I've removed it since speed is more important at this point. I don't know if this performance hit is a result of the tree being reflowed too often or if my style rule is wrong. If someone could look into this and look at the Quantify results I provided in the message, I'd appreciate it.
Summary: Slow performance when there's an image in the Messenger thread pane → [perf] Slow performance when there's an image in the Messenger thread pane
Summary: [perf] Slow performance when there's an image in the Messenger thread pane → Slow performance when there's an image in the Messenger thread pane
Whiteboard: [Perf]
Target Milestone: M11
cc'ing phil. Is M11 soon enough for this to be looked at? This means we can never try out different types of icons for different types of messages and probably that we can't put in the flagged/unread message icon(assuming these have the same problem).
Pam is this yours. Could we work on this a little earlier.
uh. What's a 'messanger 3 pane'? Left window? Right top window? Right bottom window? -pn
...and if you could point me to where you add and remove the image in the message 3 pane. I'm assuming this is an icon in the left window. Are you removing it by changing a xul file?
I think that this is referring to the thread pane (i.e., the one with all the messages). We can construct a much simpler test case if that would be useful.
Yes, it's referring to the pane in the upper right corner in Messenger with all of the message headers. When you're able to look at this, let me know, and I can help get you set up.(You can also see http://www.mozilla.org/mailnews/prefs-info.html). The following style needs to get added back into mozilla/mailnews/base/resources/skin/threadPane.css : treeitem > treecell > titledbutton { vertical-align: bottom; height: 16px; width: 16px; list-style-image: url("chrome://messenger/skin/mailMessage.gif"); } We don't need this for M7, but if we could look at this some time soon afterward I'd appreciate it. I don't know what is causing this, but based on the Quantify run, for some reason it's spending a lot of time in image code.
Target Milestone: M11 → M8
Pam, I just wanted to mention that despite what David and I thought this afternoon, this problem still exists. It turns out that when I used an icon from the Messenger folder pane, everything was fast. But as soon as I used a different gif (I tried a few different ones) things got slow again.
Status: NEW → ASSIGNED
Blocks: 9161
Target Milestone: M8 → M9
Target Milestone: M9 → M10
I've just started looking at this and can see I'm going to need some help getting a good test condition. I have seen one interesting oddity: an image request for a nonexistant image has an error msg html page sent through the imglib to decode as image data. the image is: http://messenger.netscape.com/bookmark/4_5/images/ltgreen.gif --------- Call me or come by. -pn
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
I'm going to mark this WORKSFORME. I put the icon back in and I'm not noticing any speed problems. If I notice it again, I'll reopen, but it looks like something must have been fixed since I opened this.
QA Contact: elig → lchiang
Status: RESOLVED → VERIFIED
marking verified.
You need to log in before you can comment on or make changes to this bug.