-3

  1. All browsers (by experiment) seem to render the html on the screen at about 20 Hertz (i.e. they refresh the screen about 20 times per second) - i.e. every 50 milliseconds.

  2. By researach/experiment and common observation human beings "decide things" at about 10 Herts (ten times per second) - e.g. try making ten different faces in one second - it's just possible - but not realistically any faster (its similar for tapping on keys and clicking on FOREX buy or sell buttons).

  3. Humans cant react at much faster than 10 Hertz (100 milliseconds) - i.e. we are 100 millisecond beings.

  4. But, humans CAN detect that there is an annoying "flicker" at 10-50 Herts.

  5. So the browser "screen refresh" rate is fine at about 20 Hertz for reacting to events but is not fine for humans detecting irritating HTML element "movement flicker" !

  6. However the problem is that using Javascript to move text at any rate faster than about 20 millisecond intervals produces NO SMOOTHER MOVEMENT >> (i.e. the image still flickers at the browser render rate) e.g. see the moving but visually slightly flickering text etc on www.inferix.com - look at the javascript that generates that movement if you want - its all there plain to see.

  7. So there is no way of making "smooth TV style" flicker free movement using the current browsers UNLESS we can control the browser refresh rate and set it FASTER (by using more CPU power).

  8. Does anybody at Firefox or Chrome know if there are any plans to permit the "browser HTML/JavaScript" (or the user) to set a higher screen refresh/render rate SO THAT SAY "BBC NEWS TV STYLE" graphics are possible on the browser >> because until then the experience of using the browser is going to be boring and "childish" and will never hit TV style smoothness and capability - and it badly needs to do that as otherwise the MOMENTUM for "Javascript/HTML/DOM" being the "de facto human I/O standard" will be lost to some proprietary brands of I/O (aka MS/Google/IBM/Apple) which will emerge more dominant than ever and then dominate human I/O as closed standards and protocols - so we will all be back at suare one !

CAN WE FIX OUR BROWSERS:

PERHAPS THE FIX IT IS THERE ALREADY BUT HIDDEN ?

BROWSER DEVELOPMENT EXPERTS:

HOW DO WE INCREASE THE BROWSER RENDER RATE FROM THE JAVASCRIPT OR HTML - OR ALTERNATIVELY (CPU PERMITTING) CAN YOU MAKE YOUR BROWSERS RENDER A LOT FASTER THAN THE CRRENT RATE (OF CIRCA 20 HERTZ) ?

ONE FINAL THOUGHT:

WE HUMANS ARE 10 HERTZ DECISION MAKERS AND 20 HERTZ VISUAL MOVEMENT DETECTORS >> BUT >> FOR "HTML/JAVASCRIPS/DOM" TO DOMINATE THE FIELD OF AI-HUMAN AS WELL AS HUMAN-HUMAN COMMUNICATION USING THE SAME TECHNOLOGY FOR SENTIENT AI COMMUNICATION OF EXACTLY THE SAME INFORMATION (I.E. THE ADVANTAGE IS THAT IT IS ALSO READABLE BY HUMANS AND AI), THE RENDER RATE WILL HAVE TO BE HUNDREDS OR PERHAPS EVEN THOUSANDS OF TIMES FASTER (FOR AI-AI USE), HOWEVER, THIS NOT NEEDED QUITE YET - BUT IN JUST 10 YEARS PROBABLY YES !

Thanks for any serious responses.....

A. fundamental "JavaScript/HTML/Browser" responses only please.

B. no "other languages or other program" responses thanks.

Just a student
  • 10,560
  • 2
  • 41
  • 69
Clive Williams
  • 103
  • 1
  • 8
  • please just ignore my few typos .... thanks – Clive Williams Jul 18 '13 at 13:24
  • I have expanded the tags to address Firefox Gecko Layout Engine people - basicially I am imagining a "Firefox TURBO button" that the user or HTML "clicks" to give Gecko a much larger share of CPU and hardware resources (i.e. a "Fastfox" Button). – Clive Williams Jan 30 '14 at 13:44
  • Eactly what experiments have you done to get the results you describe? Browsers can actually animate at up to 60 frames per second (ie the screen refresh rate). I suspect that your experiment was based on calling `setTimeout()` with a timeout of zero? Is that right? If so, your experiment is flawed due to limitations explicitly placed on the `setTimeout()` API; please [read my answer to this related question](http://stackoverflow.com/questions/19906947/is-there-anything-faster-than-settimeout-and-requestanimationframe/19907559#19907559) for more info, and how to get around it. – Spudley Jan 31 '14 at 13:54
  • ok thanks spudley - this is all i need for the moment - i have forgotten what i did in the experiment - it was so long ago - i will check and report back in a comment here - i will do that soon (next week) - no point in speculating until i actually check - still it seems on the face of it good news for me in that 60 Hetz would be tolerabe ! .... thanks for commenting.... Brian Serafini – Clive Williams Jan 31 '14 at 14:11

1 Answers1

2

Without a code example in the question to see where you're going wrong, I'm left to guess that you're using setTimeout() to do your animations. (that's what it sounds like anyway, and a quick glance at the site you mentioned does reveal quite a few setTimeout calls in the code)

This is a problem, because setTimeout() is "clamped" to a minimum timeout time of 4ms. This is a deliberate feature of the API to prevent run-away scripts from making the browser unusable, but it does mean that setTimeout() isn't really suited to being used for animation.

Fortunately, there is an alternative API which is explicitly designed for animation. Instead of setTimeout(), you should use requestAnimationFrame().

requestAnimationFrame() is triggered at the next available screen refresh (a maximum of 60 times per second, although it can slow down if the computer is under heavy load or if your animation script is too complex to be completed in a single refresh cycle).

There are other options as well for firing javascript events more frequently than this (please see this answer for more), but for animations you should stick with requestAnimationFrame(); that's what it's designed for.

Community
  • 1
  • 1
Spudley
  • 166,037
  • 39
  • 233
  • 307
  • thanks - thats all i need for the moment - i will investigate next week - and report back (here) - but this seems like a very good answer - and is probably all i need !!! – Clive Williams Jan 31 '14 at 14:14