Че-та я не ожидал такого... Скрыто за неполный код, ну ладно : )))

Вот вам полный, пожалуйста:

Шары:
http://sandbox.mkechinov.ru/Alisa/js/balls.js

Менюшка:
http://sandbox.mkechinov.ru/Alisa/js/menu.js

Кодировка - ЮТФ.

Сама страничка:
http://sandbox.mkechinov.ru/Alisa/

Я просто побоялся что код целиком не влезет в 1 пост... извините.

Мдя, чтото этот раздел не очень комментируется...

Хоть бы кто сказал что я лоХъ )))) вообще молчком.

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

А что ты хочешь услышать?
Что требуется оценивать?

С дизайнерской точке зрения УЖОС. Фича ради фичи.

Код более менее хотя можно и лучше сделать.

Шары почемуто отрабатывают только один раз. И непонятно что сними делать? Нормальный человек только случайно на них может нажать.

bars80080, эээм.. быть может я уже почти год нахожусь в заблуждении и не понимаю смысла этой ветви форума?

Я думал что "Наши скрипты" это место где можно выложить чтото свое и сказать, "Вот! Граждане дорогие коллеги, зоцените мое гениальное творение..."

Вопросов никаких нет, просто решил показать...

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

Видать у меня эстетический критинизм, я все время на этом попадаюсь : ))

Добавлено через 2 минуты и 35 секунд
krundetz, изначально это дело планировалась как анимация к переключающимся пунктам меню. Но после реализации 1го поворота стало ясно, что как ты и сказал, это УЖОС. И даже если с дизайнерской точки зрения это можно довести до ума, благо я сделал пачку закладок на регулировку алгоритма движения шаров... скорость, радиус и координаты центра окружности по которой они вертятся (это был полный пипец..)... Но все это дело жуууутко тормозит комп, и если мегагерцев у вас меньше 1500 то все жутко лагает, особенно если одновременно еще и левая менюшка крутится.

В принципе был бы благодарен за советы по оптимизации кода, в плане чтоб быстрее работал и меньше грузил комп - проц и оперативку...

а, ну тоды понятно. однако, я бегу по активным темам и особо не смотрю, что там за раздел. знаю только что js и всё

видел, что-то работает, но не совсем понятно зачем. как грится - концепция главное. то есть, зачем?


извини, если что не так

bars80080, ну я выше написал, что был бы рад услышать как сделать так чтобы эта конструкция меньше комп грузила.

Если ты посмотришь что творится например с сжираемой ФФ памятью во время анимации левой менюшки, придешь в ужас...

Если посмотришь на загрузку ЦП при варщении шариков, придешь еще в больший ужас...

предлагаю использовать cssText, а не style.left и прочие.

JSman, например? Есть другой способ элемент подвинуть? Не знал...

obj.style.cssText = 'left: 5px; top: 3px;'

VS

obj.style.left = '5px';
obj.style.top = '3px';

Помни одну вещь, этот трюк дожен работать быстро тогда, когда остальная "стилевая" нагрузка ложится на классы. Это я говорю о примении атрибута class. Если все-таки используеются inline стили, то лучше применять такой код

obj.style.cssText += 'left: 5px; top: 3px;';

Все упирается в тестирование. Проверь сам. И обязательно напиши.

JSman, мм.. окей, не обещаю что сразу (дел не в проворот), но обязательно посмотрю, спасибо.

JSman, я думаю это:



не коректно в данном случае так как получим в итоге следующие



что работать будет но не комильфо

krundetz, да я думаю нет проблем регулярным выражением выцепить циферки, поменять их и записать заново. Правда вот это опять же лишнее действие, да еще какое... помнится в ПХП они прилично жрут ресурсы, в JS наверное тоже, так что будет ли это оптимизацией.

Dima 2015, парсинг сам по себе высокозатратен, поэтому там где без него можно обойтись лучше обойтись.

Вообще оптимально по моему будет хранить координаты элемента как инлайн свойства а все стальные свойства элемента сделать внешними.

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

Dima 2015, счас подумал а почему бы не сделать некий вариант потока? Тоесь у нас есть функция отсчитывающия время, в нашем случае setTimeout запускающая другую функцию которая в свою очередь отсылает сигналы перемешаемым обьектам переместится в следующию точку, и уже сам обьект получив этот сигнал должен переместится в точку соответсвующию его условиям передвижения, тоесть все вычисления куда происходят внутри обьекта.

усли говорить условностями то получим следующие
                                 -> движение
интервал -> сигнал -> движение и второй раз и третий и четвертый
                                 -> движение

Тоесть основная функция у нас знает только каким обьектам отсылать сигнал обьекты мы регистрируем при старте и убираем при остановке

Матиматика может помочь курс в университете называется Числиные методы придуманы специально для облегчения компьютеру вычислений

krundetz, жжесть, а в чем выигрыш производительности будет в таком подходе? Или просто более красивая модель?

П.С. Численные методы у меня были в универе, правда мы без особой привязки к ПК их проходили, так.. всякая интерполяция, численные решения диффуров...

Dima 2015, да модель в этом случае получается красивие, и выигрыш производительности должны получить, особенно если у нас несколько одинаковых обьектов движущихся по одной траектории, но с разными начальными координатами, ну и самое главное при таком подходе ты можешь двигать любой обект на экране, достаточно только ему прикрепить свойства отвечающие за передвижение, зарегистрировать как передвигаемый и все.

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