Ответ 1
Хорошо, я знаю, что это не совсем тот ответ, который кто-то хочет услышать (и это спорный вопрос), но из-за взгляда Рафаэля и чтения комментариев выше, я не могу помочь подумайте, что это проблема сбора мусора, и это причина различных результатов для всех браузеров. С быстрым взглядом на источник Рафаэля, похоже, что несколько бит объявляется или реализуется в процессе анимации кадра на основе кадра. Я знаю, что, по крайней мере, в двигателе Chrome V8, каждый var объявляется в отслеживаемом методе и помещается в кучу, задержка в сокращении частоты кадров только дополнительно указывает на то, что сборщик мусора пинает в высокий режим, чтобы высвободить куски объявленные вары, которые больше не используются. Я бы поставил хорошие деньги, что если бы вы переместили много объявлений в Raphael script в более высокий объем (возможно, даже глобальный, gasp!!), Особенно во время анимационных последовательностей, вы найдете очень улучшенную фреймворк- в течение script.
Я столкнулся с этой проблемой в пользовательской реализации адаптации к webgl, в основном я делал команды webgl без включенного webgl. Растеризатор конвейера, который я построил, имел очень похожую проблему, как это, в основном, он рисовал бы фреймы, начинающиеся с 68 кадров в секунду, но к концу теста будет снижаться до 13 кадров в секунду или ниже и при использовании 98% процессора. Только после того, как я очистил каждую декларацию, которая создала новые выделения памяти из области конвейера (и сделала еще несколько исследований, ускоряющих трюки, связанные с переменными поисками), я наконец смог продолжить работу и создать хорошо написанный растеризатор, который может накачивать примерно 3-5 МБ/с пикселей на экран одновременно, сохраняя скорость 50-60 кадров в секунду.
Опять же, не уверен, что это ответ, который вам нужен или нужен, но я думаю, что он правильный.:( К сожалению, я не мог больше помочь. Удачи:)