108618 - investigate the cost of taskbar

Status: RESOLVED FIXED

(SeaMonkey :: General, defect)

Description

[Cathleen]

please provide a patch to remove taskbar to the bug for further analysis.

Comment 1

[Bill Law]

I removed the taskbar by commenting out the xml-overly directive for
tasksOverlay.xul in navigatorOverlay.xul.  Sorry; I don't have a patch because I
changed this "manually" in my commercial dist.

Here's the output (from 3 runs):

----- base/modern -----
00008.156: ...main1
00008.203: ...main1
00008.094: ...main1
----- noTasksOverlay/modern -----
00007.860: ...main1
00007.984: ...main1
00007.875: ...main1
avg1=8.151000 avg2=7.906333 diff=0.244667 (3.001677%)
----- base/modern -----
00008.063: ...main1
00008.265: ...main1
00008.063: ...main1
----- noTasksOverlay/modern -----
00007.860: ...main1
00008.141: ...main1
00007.922: ...main1
avg1=8.130333 avg2=7.974333 diff=0.156000 (1.918741%)
----- base/modern -----
00008.046: ...main1
00008.188: ...main1
00008.297: ...main1
----- noTasksOverlay/modern -----
00008.063: ...main1
00007.984: ...main1
00007.859: ...main1
avg1=8.177000 avg2=7.968667 diff=0.208333 (2.547797%)

So the savings seems to be somewhere between 2 and 3 percent.

By simply removing this overlay, the "Tasks" entry on the window menu bar is
empty.  And so is the task bar at the bottom of the window.  If we wanted to
defer the cost of the task bar, we could load the overlay stuff dynamically when
the Tasks submenu was opened and perhaps fill the task bar asynchronously after
the window was opened.

Before investing time in doing that, I think we should consider some technique
for merging the overlays statically (at build time) which would likely achieve
the same savings (cumulative, for all the overlays) with less volume of hacking
scattered throughout the chrome.

Comment 2

[Bill Law]

done

Comment 3

[Bill Law]

oops, forgot to resolve it...