[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fly in from right banner
I don't believe itreally recursion, though I know others have said this (I
don't always like to be the one to disagree!). Now, the comments that
internally, and Brendan could shed some light there.
When you set a timer it's a one-shot, and it sets a hook in the operating
idle, having done all its work. Becuase the function is exited it's not
recursive (recursive would be a call to the function from within the
function, and setTimeout does not do this). The timer sits in the OS's
queue, and acts more like an onEvent. When the timer pings the setTimeout
event calls whatever function is indicated.
The problem does not appear to be setTimeout called recursively, as I've
gotten it to cycle many tens of thousands of times with clock code, and it
relating to its single string object, in that it doesn't apear to perform
garbage collection consistently. The result is too many string objects.
So, this is not stack related, but heap related.
mentioned. There's also an undocumented delete function, which also works
(it simply kills the object, removing it from the heap). But Brendan says
it will be deprecated or removed in the next version. I personally hope it
I agree the timers should have a resolution below 333 milliseconds. There
are in fact many setTimeout limitations and bugs they need to address. For
example, animated GIFs funk out if you have a setTimeout event in the queue.
At 06:08 PM 2/28/96 +0000, you wrote:
>> At 12:09 PM 2/15/96 -0800, you wrote:
>> >I tried your scrolling banner at 'www.shopsite.com' and it was impressive
>> >BUT ended in a GPF in Netscape (2.05b).
>> > -Lew Barnesson, a new subscriber
>> Don't know if it'll fix the GPF, but you'll definitely want to download the
>> final of 2.0, which has been available a week or two now.
>> -- Gordon
>I have not tested this particular site but one of the problems with
>banner routines/functions is they require endless recursion. This is
>due to the current limited number of RT (real time) event handlers in
>arguments to the functions (Mr Stack... say hello to Mr Heap).
>I have seen some that will run on a Windows 8meg platform for less
>than 10 minutes. And of course if they are really screwed up, just
>loading them might cause a problem. Obviously the lastest version of
>Netscape SHOULD be better. However, I have found, as with all complex
>applications, as one thing is fixed something else is broken.
>Hey Netscape (dev/null) how about some real event handlers like:
>timers that are accurate at times below 150ms (say down to 20-30ms)
>resetTimeout(id); for imediate reuse at the selected ms delay.
For help about the list, please send a message to 'email@example.com'
with the message body 'help'. To unsubscribe, send a message to