How to write a browser based timer

Discussion in 'Javascript' started by Cal Who, Feb 21, 2012.

  1. Cal Who

    Cal Who Guest

    I need to know what to read about.

    I want to write a browser based timer such that when one presses some key it
    starts incrementing and pressing another key pauses it.

    HTML to be on the same machine as the browser.

    Timer to display minutes and seconds. (an hour max)

    At each press the timer continues to count up from the last time it was
    paused.

    What I need to know is what would be an appreciated language to study.

    Is Javascript the way to go?

    Must run on MAC or PC.

    I have some programming experience and given a direction can probably learn
    what I need to do this.

    Any examples of something close anywhere?

    Thanks for any helpful direction comments.
     
    Cal Who, Feb 21, 2012
    #1
    1. Advertising

  2. Cal Who

    Scott Sauyet Guest

    " Cal Who" wrote:
    > I need to know what to read about.
    >
    > I want to write a browser based timer such that when one presses some key it
    > starts incrementing and pressing another key pauses it.
    > [ ... ]
    >
    > What I need to know is what would be an appreciated language to study.
    >
    > Is Javascript the way to go?


    I assume you mean "appropriate language".

    You can certainly do what you want with Javascript. And it shouldn't
    be difficult.

    You need to look at three features of Javascript:

    - Keyboard Events, to listen for the keystrokes that matter
    - setTimeout or setInterval to occasionally check the time
    - DOM manipulation to display the results

    Alternately, you can probably search the web for Javascript stopwatch
    implementations and find one that either does exactly what you want or
    could easily be modified to do so.

    -- Scott
     
    Scott Sauyet, Feb 21, 2012
    #2
    1. Advertising

  3. On Tue, 21 Feb 2012 13:04:24 -0800 (PST), Scott Sauyet
    <> wrote:

    [snip]

    >I assume you mean "appropriate language".
    >
    >You can certainly do what you want with Javascript. And it shouldn't
    >be difficult.
    >
    >You need to look at three features of Javascript:
    >
    > - Keyboard Events, to listen for the keystrokes that matter
    > - setTimeout or setInterval to occasionally check the time
    > - DOM manipulation to display the results
    >
    >Alternately, you can probably search the web for Javascript stopwatch
    >implementations and find one that either does exactly what you want or
    >could easily be modified to do so.


    Are they very accurate?

    Pause a second, update, then repeat will be inaccurate because of
    the execution time being indeterminate.

    Following the clock will be somewhat more CPU-intensive.

    Assuming it exists, what is the third way that works well?

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Feb 21, 2012
    #3
  4. Cal Who

    Evertjan. Guest

    Gene Wirchenko wrote on 21 feb 2012 in comp.lang.javascript:

    > On Tue, 21 Feb 2012 13:04:24 -0800 (PST), Scott Sauyet
    > <> wrote:
    >
    > [snip]
    >
    >>I assume you mean "appropriate language".
    >>
    >>You can certainly do what you want with Javascript. And it shouldn't
    >>be difficult.
    >>
    >>You need to look at three features of Javascript:
    >>
    >> - Keyboard Events, to listen for the keystrokes that matter
    >> - setTimeout or setInterval to occasionally check the time
    >> - DOM manipulation to display the results
    >>
    >>Alternately, you can probably search the web for Javascript stopwatch
    >>implementations and find one that either does exactly what you want or
    >>could easily be modified to do so.

    >
    > Are they very accurate?
    >
    > Pause a second, update, then repeat will be inaccurate because of
    > the execution time being indeterminate.
    >
    > Following the clock will be somewhat more CPU-intensive.


    Not at all.

    During run, display every [say] 200ms:
    actualTime - lapStartTime + endCountLastLap

    During pause, display static:
    display endCountLastLap

    Reset:
    endCountLastLap = 0
    setPause


    >
    > Assuming it exists, what is the third way that works well?
    >
    > Sincerely,
    >
    > Gene Wirchenko




    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
     
    Evertjan., Feb 21, 2012
    #4
  5. On 21 Feb 2012 22:40:08 GMT, "Evertjan."
    <> wrote:

    >Gene Wirchenko wrote on 21 feb 2012 in comp.lang.javascript:


    [snip]

    >> Following the clock will be somewhat more CPU-intensive.

    >
    >Not at all.


    I am thinking yes, it will be more intensive, because the
    updating must be more often to avoid having jerky output. If the hit
    is still not that much, well and good.

    (I am leery of anything approaching busy wait, because it can
    really suck up the CPU time.)

    [snip]

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Feb 21, 2012
    #5
  6. Cal Who

    Evertjan. Guest

    Gene Wirchenko wrote on 22 feb 2012 in comp.lang.javascript:

    > On 21 Feb 2012 22:40:08 GMT, "Evertjan."
    > <> wrote:
    >
    >>Gene Wirchenko wrote on 21 feb 2012 in comp.lang.javascript:

    >
    > [snip]
    >
    >>> Following the clock will be somewhat more CPU-intensive.

    >>
    >>Not at all.

    >
    > I am thinking yes, it will be more intensive, because the
    > updating must be more often to avoid having jerky output. If the hit
    > is still not that much, well and good.


    200ms is enough, please try it out,
    but even if it were each 50ms,
    the CPU use would be do very-very-very low.

    No incrementing is done, just new Date() and some adding,
    and a DOM-innerHTML write.

    > (I am leery of anything approaching busy wait, because it can
    > really suck up the CPU time.)


    What is "busy wait"??

    setTimeout() does not take cpu-time until it fires at the end,
    since it is just an added task at the general CPU-interrupt stack,
    if that is what you mean. This task runs anyway on each machine's OS.


    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
     
    Evertjan., Feb 21, 2012
    #6
  7. On 21 Feb 2012 23:27:08 GMT, "Evertjan."
    <> wrote:

    [snip]

    >> (I am leery of anything approaching busy wait, because it can
    >> really suck up the CPU time.)

    >
    >What is "busy wait"??


    Busy wait is when a process consumes CPU time to implement a
    wait. One can delay with a for loop (busy wait) or a call to sleep()
    (not busy wait).

    >setTimeout() does not take cpu-time until it fires at the end,
    >since it is just an added task at the general CPU-interrupt stack,
    >if that is what you mean. This task runs anyway on each machine's OS.


    Well, there is a loop being executed over and over. That is why
    my comment about approaching busy wait.

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Feb 22, 2012
    #7
  8. Cal Who

    RobG Guest

    On Feb 22, 8:40 am, "Evertjan." <> wrote:
    > Gene Wirchenko wrote on 21 feb 2012 in comp.lang.javascript:
    > > On Tue, 21 Feb 2012 13:04:24 -0800 (PST), Scott Sauyet
    > > <> wrote:


    [snip]

    > >>Alternately, you can probably search the web for Javascript stopwatch
    > >>implementations and find one that either does exactly what you want or
    > >>could easily be modified to do so.

    >
    > >      Are they very accurate?


    They should be based on the system clock, so should have equivalent
    accuracy. More import is whether the stopwatch will update at the
    appropriate time, which is a function of system load at the time the
    function is scheduled to be called.

    > >      Pause a second, update, then repeat will be inaccurate because of
    > > the execution time being indeterminate.


    If it is to update at a particular interval, the function should
    calculate the milliseconds to the next full intervale and call the
    function via setTimeout very soon after that (say 20 ms for a 1 second
    timer). So the function only needs to run once per scond for a timer
    with one second resolution.

    If the resolution is 0.1 seconds, then schedule it to run say 10ms
    after the next 100 ms interval so it runs about 10 times per second.
    If system load is heavy and it misses an interval, it will appear to
    skip but there is nothing you can do about that.


    > >      Following the clock will be somewhat more CPU-intensive.

    >
    > Not at all.


    The CPU use will be (roughly) a function of how often it is called, so
    calling it less often should use less CPU.


    --
    Rob
     
    RobG, Feb 22, 2012
    #8
  9. Cal Who

    Evertjan. Guest

    Gene Wirchenko wrote on 22 feb 2012 in comp.lang.javascript:

    > On 21 Feb 2012 23:27:08 GMT, "Evertjan."
    > <> wrote:
    >
    > [snip]
    >
    >>> (I am leery of anything approaching busy wait, because it can
    >>> really suck up the CPU time.)

    >>
    >>What is "busy wait"??

    >
    > Busy wait is when a process consumes CPU time to implement a
    > wait. One can delay with a for loop (busy wait) or a call to sleep()
    > (not busy wait).


    Inconsequenttial in the case of setTimeout()

    >>setTimeout() does not take cpu-time until it fires at the end,
    >>since it is just an added task at the general CPU-interrupt stack,
    >>if that is what you mean. This task runs anyway on each machine's OS.

    >
    > Well, there is a loop being executed over and over. That is why
    > my comment about approaching busy wait.


    You are WRONG in the case of Javascript [yes, we know Thomas] and
    setTimeout().

    There is NO wait-loop here, Javascript execution finishes.

    A new Javascript execution is triggered by the CPU-interrupt routine, in
    itself an interrupt of a loop on the microcode level, but one that must run
    anyway, since the CPU is only idle if the machine is switched of.

    Even waitloops in other compilers [or interpreters?] should use a short
    sleeps in the loop to minimize CPU cycle-grabbing, Javascript has no need
    for wait loops.


    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
     
    Evertjan., Feb 22, 2012
    #9
  10. On 22 Feb 2012 15:41:57 GMT, "Evertjan."
    <> wrote:

    >Gene Wirchenko wrote on 22 feb 2012 in comp.lang.javascript:


    [snip]

    >> Well, there is a loop being executed over and over. That is why
    >> my comment about approaching busy wait.

    >
    >You are WRONG in the case of Javascript [yes, we know Thomas] and
    >setTimeout().
    >
    >There is NO wait-loop here, Javascript execution finishes.


    I stated that there was a loop, not that there was a wait-loop.

    [snip]

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Feb 22, 2012
    #10
  11. In comp.lang.javascript message <ht38k7pv0rr3vrinoj674dg70v5iic6tsq@4ax.
    com>, Tue, 21 Feb 2012 13:45:13, Gene Wirchenko <> posted:

    >
    > Pause a second, update, then repeat will be inaccurate because of
    >the execution time being indeterminate.
    >


    If you had read <http://www.merlyn.demon.co.uk/js-date0.htm#TaI>, you
    might have been able to write something more appropriate,

    --
    (c) John Stockton, nr London UK ?@merlyn.demon.co.uk IE8 FF8 Op11 Sf5 Cr15
    news:comp.lang.javascript FAQ <http://www.jibbering.com/faq/index.html>.
    <http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
    <http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
     
    Dr J R Stockton, Feb 22, 2012
    #11
  12. Cal Who

    Evertjan. Guest

    Gene Wirchenko wrote on 22 feb 2012 in comp.lang.javascript:

    > On 22 Feb 2012 15:41:57 GMT, "Evertjan."
    > <> wrote:
    >
    >>Gene Wirchenko wrote on 22 feb 2012 in comp.lang.javascript:

    >
    > [snip]
    >
    >>> Well, there is a loop being executed over and over. That is why
    >>> my comment about approaching busy wait.

    >>
    >>You are WRONG in the case of Javascript [yes, we know Thomas] and
    >>setTimeout().
    >>
    >>There is NO wait-loop here, Javascript execution finishes.

    >
    > I stated that there was a loop, not that there was a wait-loop.


    Same thing, you are wrong in thinking that, there is no loop made.

    In other worde sthere is no polling to see if the right time has come,
    the right time is when the O.S. interupt fires.

    There is no Javascript execution till triggered by the operating system,
    so there are no CPU-cycles used by the programme.


    > [snip]
    >
    > Sincerely,
    >
    > Gene Wirchenko
    >


    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
     
    Evertjan., Feb 22, 2012
    #12
  13. On 22 Feb 2012 21:55:09 GMT, "Evertjan."
    <> wrote:

    >Gene Wirchenko wrote on 22 feb 2012 in comp.lang.javascript:
    >
    >> On 22 Feb 2012 15:41:57 GMT, "Evertjan."
    >> <> wrote:
    >>
    >>>Gene Wirchenko wrote on 22 feb 2012 in comp.lang.javascript:

    >>
    >> [snip]
    >>
    >>>> Well, there is a loop being executed over and over. That is why
    >>>> my comment about approaching busy wait.
    >>>
    >>>You are WRONG in the case of Javascript [yes, we know Thomas] and
    >>>setTimeout().
    >>>
    >>>There is NO wait-loop here, Javascript execution finishes.

    >>
    >> I stated that there was a loop, not that there was a wait-loop.

    >
    >Same thing, you are wrong in thinking that, there is no loop made.


    Sure there is. The sequence that sets the timeout is repeatedly
    executed.

    >In other worde sthere is no polling to see if the right time has come,
    >the right time is when the O.S. interupt fires.
    >
    >There is no Javascript execution till triggered by the operating system,
    >so there are no CPU-cycles used by the programme.


    I know that. That is what makes it not a busy-wait.

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Feb 22, 2012
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kelsang Wangchuk

    System.Timers.Timer vs. System.Threading.Timer

    Kelsang Wangchuk, Jul 31, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    756
    Kelsang Wangchuk
    Jul 31, 2003
  2. Replies:
    1
    Views:
    1,679
    Steve C. Orr [MVP, MCSD]
    Feb 22, 2005
  3. Simon

    page timer, or redirect timer

    Simon, Nov 4, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    11,261
    Bruce Barker
    Nov 4, 2005
  4. AMC
    Replies:
    12
    Views:
    393
    Roland Hall
    Jan 13, 2005
  5. Replies:
    8
    Views:
    632
    Jorgen Grahn
    Jul 15, 2013
Loading...

Share This Page