Very slow on Windows Safari and iPad about jsc3d

[GoogleCodeExporter]

into the init method of the Viewer where the rendering loop is triggered i 
chnaged that:
setInterval(function(){self.doUpdate();}, 30 );

into:

    window.requestAnimFrame = (function(){
        return  window.requestAnimationFrame       ||
            window.webkitRequestAnimationFrame ||
            window.msRequestAnimationFrame ||
            window.oRequestAnimationFrame ||
            window.mozRequestAnimationFrame    ||
            function( callback ){
                window.setTimeout(callback, 1000 / 1000);
            };
    })();

    function renderFrame(){
        self.doUpdate();
        requestAnimFrame(renderFrame);
    }

    requestAnimFrame(renderFrame);

and now the speed is really good in safari 5.1.7 for Windows

I didn't tested it on safari for mac and ipad but once I'll test it I'll be 
back with a comment (tommorw at the office i'll do the mac and ipad test)

Original comment by [email protected] on 11 Jul 2013 at 10:14

[GoogleCodeExporter]

see this for details: 
https://developer.mozilla.org/en-US/docs/Web/API/window.requestAnimationFrame?re
directlocale=en-US&redirectslug=DOM%2Fwindow.requestAnimationFrame

Original comment by [email protected] on 11 Jul 2013 at 10:27

[GoogleCodeExporter]

Tested on:
1. iMac 10.8.4
    Safari 6.0.5
    Firefox 22.0

2. IPad 2 (iOS 6.1.3)
    Safari
    Dolphin

3. Windows 7
    Safari 5.1.7
    Chrome 28.0.1500.71 m
    Firefox 22.0
    IE (9 and 10)


(On ipad and safari for windows is faster than before but still slower than 
other browsers.)

Original comment by [email protected] on 12 Jul 2013 at 7:28

[GoogleCodeExporter]

Thanks Vasile! I'll look into this solution as soon as possible.

Original comment by [email protected] on 13 Jul 2013 at 1:46

[GoogleCodeExporter]

An extra hint..

the low speed framerate is caused by 2 reasons:

1. the calculations are a bit slower on some browsers (that's a fact and we all 
know that is not possible to have exactly the same rendering speed for all the 
browsers because some javascript engine implementations are faster and other 
browsers have slower engines)

2. this call setInterval(callback, 30); will try to execute the callback every 
30millisecconds. 

when a new call is triggered if the previous call is not ended then the new 
call is queued  and will wait for it's time to be executed; and here is the 
problem... (the timer will slow down when the queue will grow and the 
performance will go down over time)

in the jsc3D engine the timer is set to render a frame each 30 milliseconds but 
if you increase the timer (to 100 for example) you'll realize that the 
rendering speed will be better in safari (because the queue will grow up 
slower) so the optimal algorithm is to invoke the next rendering call 
immediately after the current one is ended.

this code:

1. function renderFrame(){
2.        self.doUpdate();
3.        requestAnimFrame(renderFrame);
4.    }

5.    requestAnimFrame(renderFrame);

will call the next renderFrame after self.doUpdate() (line 2 and 3) and then 
why is not ok to use:

1. function renderFrame(){
2.        self.doUpdate();
3.        renderFrame();
4.    }

because this code will stay in a infinite loop and will lock the UI and will 
keep the cpu at 100%. but requestAnimFrame(function) will tell the javascript 
engine to call this method but without locking the execution only in this loop 
and the browser will do it in the best momment.

Original comment by [email protected] on 13 Jul 2013 at 6:36

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Yes, you get it!

I rewrote the code replacing setInterval() with setTimeout(). Now the relavent 
part looks like this:

  var self = this;
  (function tick() {
    self.doUpdate();
    setTimeout(tick, 30);
  }) ();

The new implementation will not send next request until the current update 
operation is completely done, thus avoids any additional call to be put to the 
queue. I tested this in my webkit base browser and was glad to see it wroks 
really smoothly.

I also wrote a requestAnimationFrame implementation for that. Though some 
technical introduction on requestAnimationFrame looks rather promising, 
unfortunately it seems to make no difference with the old setInterval() version 
in my own test (based upon webkit 535.12).  Anyway, I'll continue to pay 
attention to this.

The fixup will be commited to the repository in one or two days.

Thanks again!

Original comment by [email protected] on 13 Jul 2013 at 2:58

[GoogleCodeExporter]

Hey,

the requestAnimationFrame is supported starting with safari6 so the safari for 
windows is not using it for now that's why I used: 

 window.requestAnimFrame = (function(){
        return  window.requestAnimationFrame       ||
            window.webkitRequestAnimationFrame ||
            window.msRequestAnimationFrame ||
            window.oRequestAnimationFrame ||
            window.mozRequestAnimationFrame    ||
            function( callback ){
                window.setTimeout(callback, 1000 / 1000);
            };
    })();

if the browser does not have implemented one of the requestAnimationFrame  or 
webkitRequestAnimationFrame ... will use the default one:
function( callback ){
                window.setTimeout(callback, 1000 / 1000);
            };



I want to thank you for this nice project which I used in a real project for a 
3D presentation of products. 

http://www.berendsen.dk/new_3d  (chose a product from the dropdown and you'll 
see a popup with the 3d engine at work)


I would like to contribute as much as possible to this project because we 
really need it for 3D web presentations of products until webGL will be 
available in all the browsers.

and when the time will come a new renderer could be added for webGL and the 
engine will not die.

Original comment by [email protected] on 13 Jul 2013 at 6:52

[GoogleCodeExporter]

The requestAnimationFrame() is not found in webkit 535.12. Instead it provides 
a private alternative webkitRequestAnimationFrame() which is tested not to be 
as powerful as the official document says. Maybe its implementation is not done 
in the 535.12 edition.

A WebGL rendering backend is worth consideration. While there will be a lot of 
things to do to implement that. Currently I just haven't got enough time to 
complete it.

Your project is really cool! However it seems do not work in my 
InternetExplorer. IE9 and IE10 already make good support for most HTML5 
features especially canvas drawings. Their javascript engine are also 
re-written to provide enough power to these type of applications. You could try 
to modify your page's description and add this

  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 5.0 Transitional//EN">

It may help your product page to be also compatible with modern IEs.

I'm glad to see jsc3d is used in such serious applications :-)

Original comment by [email protected] on 14 Jul 2013 at 1:26

[GoogleCodeExporter]

Sorry but I have to ask you what version of IE you have ?

during the testing process it was working well on all ie versions:

IE8 -> flash implementation
IE9+ -> html5 implementation

could you let me know what's happening in your system? (freezing, not 
loading... )

Strangest part is that QA department did not report the issue (neither the 
Berendsen staff)

(you could write by email directly not to post on this page things not related 
to jsc3D)
Thank you. 

Original comment by [email protected] on 14 Jul 2013 at 7:14