On Wed, Jan 08, 2014 at 11:49:56AM +0100, laurent bernabe wrote: > Thank you very much : so I undestand that this is at the same time a > software and a hardware (with temperatures) concern. And that the > process can be different in cases of raster based programs and > vector based programs. > > Unfortunately, I can only test programs on my two computers (an old > PC and a recent laptop) : so the hardware part will hardly be tested > by my means.
True, but if you make a simple test available, others can test it for you. Especially so if you can figure a way to give the test report on screen, like a frame rate achieved. > Meanwhile, when I asked this question, I had in mind that a > suggested range of values, as a guideleness, can be known : perhaps > not now, as, like you pointed me, one may not have enough > informations and tests in order to "fetch" those values. Yes, it is not practical to have a suggested range given the number of variables. However, designing for higher values can have benefits ... in research for Netrek it was found that: - five frames per second is a minimum for perception of motion, but most users will perceive the steps and use them as the basis for their reaction, such that when the rate is increased their training has to be redone, - ten frames per second is preferable, with most users still perceiving the steps, - 25 frames per second is very good, with most users not perceiving the steps, - 50 frames per second is excellent. > And also, as I've been told on this mailing list, there is a new > Javascript API in order to let the computer(web browser ?) hold this > value for the programmer. > > So I think the "issue" can easily be solved : at least with this > requestAnimationFrame() function. Great. -- James Cameron http://quozl.linux.org.au/ _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel