krundetz, пожалуй... вынес в класс постоянные параметры, правда вот на работе оценить не могу стало ли лучше, тут комп мощный, и так все летает.

Думаю разница будет заметна при большом количестве(несколькор сотен а может и тысячь) передвигаемых обектах 

krundetz, у меня объекта 4 всего. Зато вот делается это очень часто - ф-ции движения сами себя вызывают раз в 20-50 мсек (хотя это условно, на самом деле JS так быстро уже не работает)

И таких ф-ций 4 штуки - на каждый шар своя, поэтому наверно и тормозит все. И ф-ции содержат довольно сложные вычисления - корни там всякие... бррр

Убери parseFloat вообще, отовсюду, необходимости в нём там нигде нет, а на него куча ресурсов уходит...
Подсказка, все изменяемые св-ва храни в shadow[i], а стили будут тогда меняться примерно так:

source777, вообще логично. Т.е. нужно тащить с собой всю дорогу значения изменяемых свойств в свойствах объекта, а не снимать их каждый раз непосредственно с элемента. В некоторых местах у меня вроде так и сделано, но не везде. И при необходимости изменения меняем значение свойства объекта а св-во хтмл-элемента устанавливаем равному этому значению ну и + 'px', вроде верно понял твою мысль... сделаю.

Вот немного оптимизированный код, отпишись о результатах сравнительного тестирования... 

source777, поставил твой код.

На машине 1 ГГц и 496 ОЗУ не тянет. Лагает очень сильно. На моих 2х ГГц-ах  1 Гб ОЗУ летает, в прочем как и раньше. А среднего у меня нету для тестов...

Это сообщение отредактировал(а) Dima 2015 - 26.9.2008, 17:08

Не, не, не. Это твой код, просто нормально записанный! А алгоритм я не трогал.

Кстати что касается скорости работы, то тут уже больше от браузера зависит, а не от компьютера... Для начала можешь скорость увеличить:

source777, ну в твоем варианте parseFloat не используется при каждом акте движения, я это и имел в виду, но особо легче от этого не стало.

А касаемо скорости - трудно судить, просто на слабых машинах эта менюшка лагает в прямом смысле этого слова. Как знаешь, во времена 133-х пентиумов новые игры, которые еле еле запускались и по кадрам показывались, вот такая фигня...

Я такого слова не знаю, поясни. Слабые это кстати какие? Я тестил на 512 Мб ОЗУ, 1700 MGz и всё летает. Расскажи как именно ты производишь замеры производительности? это очень важно...

source777, хех... если б я умел грамотно делать замеры производительности... Ну я умею посмотреть сколько памяти съедает Фаерфокс и какова загрузка ЦП в момент анимации (alt+ctrl+del - вкладочки процессы и быстродействие соответственно). Сейчас вот показывает порядка 50% в момент анимации теней и 64% если одновременно еще шары начать крутить.

Касаемо памяти мне кажется это необъективный критерий. Ибо очень сильно от браузера зависит, ФФ например всегда оперативки кушала за троих...

Теперь по поводу лагает. Представим себе элемент div, к которому применяется ф-ция движения. Эта функция двигает элемент на 1 px скажем влево и вызывает сама себя через 10 мсек. Таким способом я реализую плавное движение элементов:

Вроде должно работать если скопировать...


Клик на div приводит к тому что он ПЛАВНО едет вправо, с постоянной скоростью, без остановок, как говорили в школе - равномерно и прямолинейно 

Так вот "лагает" это когда равномерность движения теряется. Проедет немного, остановится. подумает, снова проедет еще немного, в целом движение происходит гораздо медленнее чем когда "не лагает".  Некая имитация, для того чтоб проиллюстрировать "лаги" может быть получена если ф-цию move в примере записать так:



Собственно уже на этом примере видно как подпрыгивает загрузка ЦП при движении. А теперь представим что ф-ций таких не одна а 6 (грубо говоря на каждый пункт меню - своя), и каждая делает не просто сдвиг на 1 пиксел влево, а расчет координат, проверки и тд и тп...

Я так понимаю это и загружает ЦП.

Это сообщение отредактировал(а) Dima 2015 - 27.9.2008, 23:59

А ты сделай через 50 мс. и на 5 px, зрительная плавность движения от этого ничуть не пострадает, а нагрузка на комп значительно уменьшится.

source777, ну это то понятно. Это я для примера привел, реально у меня как раз шаг порядка 3-4 пикселей. Больше уже не получается, ставить более 6 пикселей - становится заметно равное движение.

Однако, как я понимаю, неверно что

Двигать на 1px и ставить setTimeout('move()', 10) эквивалентно тому, чтоб двигать на 5 px и ставить setTimeout('move()', 50).

Когда в ход идут такие маленькие интервалы времени то JS (или это косяк браузера) не точно работает. Точные интервалы он выдает гдето до 100 мсек, это уже обсуждалось ранее, к сожалению не смог найти ту тему. Ну досаточно запустить ф-цию, которая будет увеличивать переменную а (изначально равную 0) на 1 и вызывать сама себя через 10 мсек и посмотреть до скольки добежит а за 10 секунд. Теоретически то должна добежать до 1000, однако реально будет много меньше. Все это я к тому, что увеличивая шаг движения в 5 раз интервал вызова ф-ций придется подбирать вручную, чтоб визуальная скорость сохранилась.

-------
-------

Мне тут оригинальную идею предложили, относительно шаров. У меня сейчас они вращаются с использованием ур-я окружности. Т.е. меняем left на какое-то значение шага (3-4 пиксела) и пересчитываем top исходя из ур-я окружности. Но есть и другой вариант вращения объекта. Такая штука как матрица поворота из лин. алгебры. Можно ее попытаться использовать. Реально, как я понимаю это замена вычисления

var x = Math.floor(Math.sqrt(ball[3].radius * ball[3].radius - y*y));

на 4 операции умножения и 3 операции сложения, черть его знает что легче...

Однако реализация такой штуки меня немного настораживает, принимая во внимание специфику JS и браузера... математически красиво, а что из этого выйдет...

deleted

Это сообщение отредактировал(а) Dima 2015 - 13.12.2008, 10:27