Во время перекомпиляции или рестарта ASP.NET-приложения я регулярно наблюдал картину, когда процесс firefox использовал процессор не меньше, а то и больше, чем aspnet_wp. С какой, спрашивается, радости он это делает, если он просто ждет ответа от сервера? На что тратится ресурс процессора?
Ответ на этот вопрос был заметен, оказывается, невооруженным взглядом, но он настолько дурацкий, что подумать его было сложно. Процессор кушает… анимация (APNG) крутящегося индикатора загрузки! Достаточно заменить его статическим png (или анимированным gif), чтобы проблема ушла.
Злополучный файл называется loading_16.png. Я нашел его здесь:
Ура, теперь не надо обдумывать переход на другой браузер! :) Надеюсь, в 3.5 это все-таки исправят, как-то неохота повторять операцию после апдейта.
Другой вариант решения — скопировать вот это в userChrome.css (не пробовал, это информация с баг-трекера Мозиллы).
Ссылки с подробностями:
https://bugzilla.mozilla.org/show_bug.cgi?id=437829
forum.mozilla-russia.org/viewtopic.php?pid=315838#p315838
Ответ на этот вопрос был заметен, оказывается, невооруженным взглядом, но он настолько дурацкий, что подумать его было сложно. Процессор кушает… анимация (APNG) крутящегося индикатора загрузки! Достаточно заменить его статическим png (или анимированным gif), чтобы проблема ушла.
Злополучный файл называется loading_16.png. Я нашел его здесь:
Mozilla Firefox\chrome\classic.jar\skin\classic\global\icons\
, — и заменил на статическую картинку. Также он лежит в skin\classic\aero\global\icons\loading_16.png
, но это, видимо, для Висты, а у меня XP. Там я его оставил.Ура, теперь не надо обдумывать переход на другой браузер! :) Надеюсь, в 3.5 это все-таки исправят, как-то неохота повторять операцию после апдейта.
Другой вариант решения — скопировать вот это в userChrome.css (не пробовал, это информация с баг-трекера Мозиллы).
Ссылки с подробностями:
https://bugzilla.mozilla.org/show_bug.cgi?id=437829
forum.mozilla-russia.org/viewtopic.php?pid=315838#p315838