AKS, 

да, это я уже заметил в предыдущем посте (там, где updated). За пример - спасибо. Действительно, такой параметр приходит, причем первым, - и только в FF. Для IE и Opera - undefined.


покажите и мне, если не затруднит =) тоже интересно )


не совсем понятно. Такое ощущение, что IE и Опере по-барабану на это "упущенное время", они "тупо" начинают выполнять setInterval'ы и setTimeout'ы после "освобождения ресурсов", потому что и в IE и в Опере - отсчет начинался с 0 - "согласно расписанию", а в FF - тоже с 0 (а не с 17, как выяснилось в моей последней поправке), но - с "учетом потерянного времени", которое, как оказалось - передалось первым параметром! Хм... +1.

Добавлено через 13 минут и 10 секунд

а что насчет неодинаковых интервалов?

Да чего же тут трудного , пожалуйста - Creating time delays.

А что, так и есть. Выполняют код, когда движок освободится (он же single-threaded как-никак).


Да незнаю пока - не сталкивался...


Это сообщение отредактировал(а) AKS - 24.9.2007, 20:20

Другая ссылка про lateness.
И ещё.
И ещё.

Правда, на мой взгляд это никак не объясняет поведение setInterval в коде dsCode.

Это сообщение отредактировал(а) Zeroglif - 24.9.2007, 20:58

использование window.setTimeout - это как-то не в ооп стиле  для полноты картины предлагаю использовать:

var func= function( ){ alert( 1 ) };
window.exec( func );

Вот как-раз, чтобы поправить вот это:

Не обязательно первым, а первым "свободным индексом" в объекте аргументов.



window.execScript может быть? А как им заменить window.setTimeout?


Это сообщение отредактировал(а) AKS - 24.9.2007, 20:54

window.exec= function( func ){
    return func( );
}

 заменить, конечно не сможет, зато запуск функции с задержкой и без оной будут производиться однотипно - через window

Это сообщение отредактировал(а) cruelangel - 24.9.2007, 21:15

Вот только хотел спросить: как эта задержка может быть отрицательной? Я добавил в пример dsCode вывод arguments[0] - если для первой итерации она составляет порядка 8000 мс, то к 15-й при некоторых запусках постепенно уменьшается до отрицательной величины -4000 - -6000. Далее, по идее, должен идти штатный режим, но и при нем задержка то колеблется в пределах ±15 мс около нуля, а то... около -1000. Получается, что таймер "заодно" выполняет и следующую итерацию - ради оптимизации рендеринга, что ли? Или это артефакт? Как объяснить эту странность?

Это сообщение отредактировал(а) SelenIT - 24.9.2007, 22:10

Получается, что таймер ждёт, когда откроется форточка, чтобы в неё влезть, но, если в IE до её открытия в очереди стоит всего одно "переждавшее" действие, то в FF - все "переждавшие" по времени к моменту открытия форточки. Поэтому к выходу из loop-а никто ничего ещё не сделал, но уже приготовился сделать - IE приготовился изменить innerHTML(IE) один раз, FF несколько раз подряд. Так примитивно выглядит со стороны (найти бы того, кто почитает код симанки...).

Вот ещё странности со сдвоенными setInterval, там же очередная ссылка на багзилу.

Zeroglif, с "переждавшими" действиями более-менее понятно, но все-таки, откуда могут взяться "отрицательные" задержки? Неужели таймер пытается "втиснуть" в эту открывшуюся "форточку" не только все "переждавшие" действия, но и пару-тройку "недождавших" (как бы "на всякий случай, а то когда еще придется...")? Или же они - мой личный глюк?

don't know

Это их глюк. У них же там бардак полнейший! Вот, например из ссылок Zeroglif'а, первый рапорт об аргументе с задержкой датирован 1999 годом. Пишут: "Надо бы сделать одно из двух - убрать эту отладочную ин-фу, или хотя бы задокументировать". Потом, 2004 год: "Посмотрели, поискали - оказалось, что до сих пор не задокументировали". С интервальными глюками, так вообще - полгода писали-писали другу другу, в конце концов Брендан: "Кто-нибудь займитесь этим глюком - у меня нету времени!". Ну вот и занимаются до сих пор... 
Короче говоря, то ли для них это серьезная проблема, что решить никак не могут, то ли просто плюнули на это все. А что вообще ждать от бесплатного софта? 
В этом плане IE, все эти годы работая без подобных проблем, и уже, как многие считают, находясь в "преклонном возрасте", выглядит молодцом. Честь и хвала разработчикам IE, которые написали такой стабильный в этом плане движок!

// Leave an extra slot for a secret final argument that
// indicates to the called function how "late" the timeout is.

хакеры, блин Ж-)


> Честь и хвала разработчикам IE, которые написали такой стабильный в этом плане движок! 

в каком плане?

Это сообщение отредактировал(а) cruelangel - 25.9.2007, 11:03

cruelangel, в каком плане? Специально дошел до тавтологии, да еще и выделил курсивом, чтобы акцентировать мысль на том, что обсуждалось. Поясню.
Всем этим "недоразумения" с Gecko'вским поведением в плане setInterval, я решил противопоставить IE'шную стабильность. Просто IE никогда не давал мне повода беспокоиться о том, что в каком-нибудь dhtml у меня появятся явные проблемы, вроде "тормозов" или "аритмии", ну или еще чего. Вот за это и спасибо разрабам IE.

Мне, на самом деле, без разницы - IE, Gecko, Opera. Просто на форумах большинство "балдеет" от FF, незабывая "пнуть" IE. "Текут слюни и сопли" от современных "классных" возможностей FF, при этом народ не знает, что есть "копнуть" FF, то окажется, что "нутро гниловато" - древнейшие баги не исправлены. 
У всех, конечно же, свои недостатки. Но есть и отлично реализованные возможности. Почему бы об этом не сказать пару добрых слов? Даже в адрес не "модного" браузера...

Это сообщение отредактировал(а) AKS - 25.9.2007, 14:11

А я IE люблю,  для людей сделан, а не для программистов.  

Не примите смайлик на свой счет...  

Это сообщение отредактировал(а) Ghirik - 25.9.2007, 14:37

и в чём же тут баг? вполне логичное поведение. если задал период в 1 секунду - получи 10 срабатываний за 10 секунд. если разработчик написал функцию, которая за эту секунду не успевает отработать - получай тормоза.



Это сообщение отредактировал(а) cruelangel - 25.9.2007, 17:35