Ох ты ж господи. Ещё раз повторяю, был вопрос "Много элементов?", был ответ "Да, можно меньше". Я ничего не советовал. С учетом id-шников, inline-стилей и ссылок с псевдо-адресом javascript:, количество элементов не главная ваша проблема. Оно может и проблемой-то быть перестанет.

На иконках убрал id, inline-стили и ссылки с псевдо-адресом javascript. Вот что получилось:

<div style="z-index: 210; left: 10px; top: 50px; background-image: url(http://rss2banner.com/desktop/img/kwrite.png);" class="IconCSS" title="Блог">
 <a>Блог</a>
</div>

что-то все также и дальше тормозит.

события так назначаются:
obj.onmouseover = function() { this.onmousedown = IsDown;} может из-за этого? addEventListener/attachEvent - лучше будет?

У меня иконки не тормозят.

Будет лучше, но не из-за скорости.

А вы я так понимаю вылечили "баг" IE? Плохое решение.

Эвалы можно всё-таки убрать, прогнать весь код профилировщиком, оптимизировать все медленные функции.
Окна при перетаскивании жутко тормозят на моём двухъядерном проце...
Вероятнее всего, что из-за прозрачной картинки при перетаскивании.
Я уверен, что окна на дивах будут работать быстрее (у меня есть пример, который работает без тормозов, но показать его я не могу из коммерческих соображений).

чем плохое?

ZoNT,
верю. сначала с иконками надо разобраться.

Стоит мне при перетаскивании иконки чуть выскочить за пределы экрана, как иконка "выскальзывает". Она не должна отпускаться, пока я кнопку мыши не отпущу.

Скорость рендеринга зависит от:
1. аппаратной части (процессор, видеокарта)
2. загруженности процессора и оперативной памяти
3. браузера (движок, дополнительные плагины и расширения)
4. сложности DOM-дерева и алгоритма JS-кода.

Оптимизировать мы можем только четвёртый пункт, что само по себе мало для существенной оптимизации. Учитывая, что событие mousemove во всех браузерах происходит очень часто (настолько, насколько позволяют первые 3 пункта), это не может не напрягать процессор (т.к. все расчеты лежат именно на нем, а не на видеокарте) и является узким местом в любом интерфейсе. Поэтому необходимо найти те решения, которые оптимизируют DOM, а так же программный код. Этим я и предлагаю тебе заняться самому, а не ныть здесь.

Как раз только что перечитывал http://clubs.ya.ru/yacf/replies.xml?item_no=338 :)

Это реализовано специально. Вышел за окно - значит отпустил кнопку. А то выкинешь ее и забудешь где-то там в небытии. Это не обязательно, и именно это не есть собственно решением для бага IE о котором упоминали. Решение бага в том, чтобы проверять при drag состояние клавиши. Если она отжата, то выполняем вашу логику отпускания кнопки. Хорошее оно или нет судить вам.

B~Vladi,
Никто не ноет. Просто интересуюсь. И уже есть какой-то результат. Уверен все будет ОК.

Воооот.

Сделал окна на дивах.

http://mugtug.com/sketchpad/ в этом редакторе окошечки с прозрачностью, таскаются, не тормозят... Никаких эффектов "гонки за мышью"...

ZoNT, на этой странице элементов всего ничего (530) и текста почти нет, скругление картинкой. также изменение размера только по s-w . да и ничуть они не быстрее.

Замерил через DynaTrace рендеринг.
Результаты при перетаскивани:

0.04ms - пустой фрейм или без фрейма в окне
0.03ms - непрозрачное окно
0.02ms - без фона на странице

0.10ms - с фоном на странице, с прозрачностью и с фреймом.

какие выводы можно сделать?

P.S. Кстати если окна малых размеров, то меньше область рендеринга.

Не использовать iframe.

Гениально! Они, к сожалению, нужны. Есть вопрос. Для получения размера области кроме offsetWidth offsetHeight clientWidth clientHeight методов есть еще какие-то? Какие из них работают быстрее?

На моём слабеньком компе они раз в 100 быстрее чем эти вебокна. Лень заморачиваться с созданием видео, а так бы показал какое слайдшоу устраивают вебокна при перетаскивании (в любом браузере, в том числе и в Хроме)...

Зачем?

Kolyaj,
ну а как еще можно показать содержимое другой страницы внутри окна?

А зачем их хранить как полноценные страницы, если они ими не являются?

limonad, замени фреймы AJAX-ом.

Заметил одну интересную вещь:
если при драге ничего больше не делается, кроме установки left и top (ну и аналогичных вещей) - браузер пытается оптимизировать рендеринг путем уменьшения fps. Как итог - тормоза.
Таблетка - принудительный reflow. Необходимо обратиться к любому из свойств (любого элемента):
innerWidth, innerHeight (как вариант).

Необходимо только протестить, какие параметры элемента влияют на скорость вычисления размера (и влияют ли вообще).

Попробовал reflow, рендеринг вырос до 0.12. Нашел кое-что по теме рендеринга: http://webo.in/articles/all/2009/31-...flow-relayout/ . Правда и там не всему можно верить. Например, там написано, что так делать плохо:

el.style.left = left + "px";
el.style.top  = top  + "px";

лучше мол так:

el.style.cssText += "; left: " + left + "px; top: " + top + "px;";

я попробовал, второй вариант значительно медленнее работает.

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

За-то тормозов нет.
Сайт в сайте? Может не стоит так далеко уходить?
Аха, я тоже читал. Может попробовать менять margin?

Да, забыл. В ИЕ8 рендеринг медленнее, чем в прошлых версиях (в 6 самый быстрый). Можно перевести его в режим ИЕ7 - помогает.

Что вы думаете о такой идее? При старте драга из divа содержащего фрейм запомнить в какой-то пременной его innerHTML и тут-же в div записать innerHTML=''. А при окончании драга вернуть в div то, что запомнили. (но тут наверное может потеряться содержимое фрейма если там был сделан переход по ссылкам, да и скрол потерятся если был.). Может есть еще какой-то вариант весь этот узел с фреймом убрать куда-то на время переноса так, чтобы он не пересчитывался и не рендерился? Подскажите.

Не прокатит: потеряются все обработчики событий. Содержимое можно просто скрывать или перенести в другое место: эффект тот-же.

B~Vladi, содержимое скрывается итак. Я хотел бы избавится от фрейма вообще на время драга. Все таки без фреймов быстрее работает. А обработчики мне для фрейма не нужны, их у него нет. Как бы удалить этот фрейм на время из DOMa.

Я же сказал - перенести:

oldElement.appendChild(frame);

А oldElement - скрывай.

Лучше тогда

var df = document.createDocumentFragment();
df.appendChild(frame);


// и обратно
div.appendChild(df);

О идеально:)

Попробовал оба варианта. Неподходит, потому что скрол в фрейме не запоминается и если я до этого внутри фрейма переходил по ссылкам или на странице внутри фрейма исполнялся js, то при возврате фрейма в родной див окна, там показано начальное содержимое, а не то что там изменялось до переноса (вообще происходит загрузка документа по новой). При этом скорость рендеринга чуть чуть выросла конечно стала 0.08мс, но толку от этого.

а если делать display: none?

Так и было сделано и есть. Просто думал, что если выдернуть фрейм из окна то станет лучше.

Дк запомни.
Так быть не должно. Ошибка у тебя где-то.

Врядле там ошибка в двух действиях. Фрейм заново грузит документ при appendChild из DocumentFragment или из div . Не имет значения из чего. А не надо случаем сам DocumentFragment добавить в какой нить контейнер?

Сейчас используется не display: none, а visibility: hidden

Мараторий, на localhost был display. поставил display на сервер.