Re: [sage-devel] Re: three.js on 7.5 beta 5: cpu...

2016-12-04 Thread William Stein
On Sun, Dec 4, 2016 at 10:37 AM, Dima Pasechnik  wrote:

>
>
> On Saturday, December 3, 2016 at 10:34:50 PM UTC, Paul Masson wrote:
>>
>>
>>
>> On Saturday, December 3, 2016 at 2:30:36 PM UTC-8, William wrote:
>>>
>>> On Sat, Dec 3, 2016 at 2:28 PM, Paul Masson 
>>> wrote:
>>> > There's apparently no good way in general to test whether the scene is
>>> > unchanged. This is a known issue:
>>> >
>>> > https://github.com/mrdoob/three.js/issues/7670
>>> >
>>> > One of the comments on this thread offers another option: only render
>>> the
>>> > scene upon user interaction. I'm so accustomed to writing Three.js to
>>> be
>>> > ready for animation that I didn't think about this. If we restrict
>>> Three.js
>>> > usage in Sage to static scenes then CPU usage drops to nothing.
>>
>>
> to me this screams of wrong design, don't know whether it's in three.js or
> just in js...
>

It is wrong design.


> Indeed, the renderer can be awaken by user interaction,
> as you say. Why can't it be awaken by an animation function?!
> How come rotating picture by hand is different from, say, rotating a part
> of it by
> a function?
>

Yes, all those problems can be solved.


>
>
>>> >
>>> > I'm happy to make this change, but this means no animations in the
>>> scenes
>>> > for now.
>>>
>>> What kind of animations are currently implemented?
>>> I can only think of spin=[number].
>>>
>>>  -- William
>>>
>>
>> None right now, but the changes necessary to get rendering to work
>> without an animation loop don't play nicely with requestAnimationFrame.
>>
>
> IMHO the default should be not to eat CPU cycles needlessly, even if it
> means having two different implementations.
> Thanks goodness running several show() commands in different browser
> (Chromium 55 - I compile
> browsers from source these days :-)) tabs only seems to invoke one
> instance of the CPU-cycle eater, not one per each tab...
>
>
You can also test SMC sage worksheets, where the 3d scene is replaced by an
identical static png whenever the mouse isn't over the actual 3d output, so
a worksheet with dozens of 3d scenes at once works fine...


-- 
William (http://wstein.org)

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: three.js on 7.5 beta 5: cpu...

2016-12-04 Thread Dima Pasechnik


On Saturday, December 3, 2016 at 10:34:50 PM UTC, Paul Masson wrote:
>
>
>
> On Saturday, December 3, 2016 at 2:30:36 PM UTC-8, William wrote:
>>
>> On Sat, Dec 3, 2016 at 2:28 PM, Paul Masson  
>> wrote: 
>> > There's apparently no good way in general to test whether the scene is 
>> > unchanged. This is a known issue: 
>> > 
>> > https://github.com/mrdoob/three.js/issues/7670 
>> > 
>> > One of the comments on this thread offers another option: only render 
>> the 
>> > scene upon user interaction. I'm so accustomed to writing Three.js to 
>> be 
>> > ready for animation that I didn't think about this. If we restrict 
>> Three.js 
>> > usage in Sage to static scenes then CPU usage drops to nothing.
>
>
to me this screams of wrong design, don't know whether it's in three.js or 
just in js...
Indeed, the renderer can be awaken by user interaction,
as you say. Why can't it be awaken by an animation function?!
How come rotating picture by hand is different from, say, rotating a part 
of it by 
a function?


>> > 
>> > I'm happy to make this change, but this means no animations in the 
>> scenes 
>> > for now. 
>>
>> What kind of animations are currently implemented? 
>> I can only think of spin=[number]. 
>>
>>  -- William 
>>
>
> None right now, but the changes necessary to get rendering to work without 
> an animation loop don't play nicely with requestAnimationFrame. 
>

IMHO the default should be not to eat CPU cycles needlessly, even if it 
means having two different implementations.
Thanks goodness running several show() commands in different browser 
(Chromium 55 - I compile
browsers from source these days :-)) tabs only seems to invoke one instance 
of the CPU-cycle eater, not one per each tab...

 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: three.js on 7.5 beta 5: cpu...

2016-12-03 Thread Paul Masson


On Saturday, December 3, 2016 at 2:30:36 PM UTC-8, William wrote:
>
> On Sat, Dec 3, 2016 at 2:28 PM, Paul Masson  > wrote: 
> > There's apparently no good way in general to test whether the scene is 
> > unchanged. This is a known issue: 
> > 
> > https://github.com/mrdoob/three.js/issues/7670 
> > 
> > One of the comments on this thread offers another option: only render 
> the 
> > scene upon user interaction. I'm so accustomed to writing Three.js to be 
> > ready for animation that I didn't think about this. If we restrict 
> Three.js 
> > usage in Sage to static scenes then CPU usage drops to nothing. 
> > 
> > I'm happy to make this change, but this means no animations in the 
> scenes 
> > for now. 
>
> What kind of animations are currently implemented? 
> I can only think of spin=[number]. 
>
>  -- William 
>

None right now, but the changes necessary to get rendering to work without 
an animation loop don't play nicely with requestAnimationFrame. 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: three.js on 7.5 beta 5: cpu...

2016-12-03 Thread William Stein
On Sat, Dec 3, 2016 at 2:28 PM, Paul Masson  wrote:
> There's apparently no good way in general to test whether the scene is
> unchanged. This is a known issue:
>
> https://github.com/mrdoob/three.js/issues/7670
>
> One of the comments on this thread offers another option: only render the
> scene upon user interaction. I'm so accustomed to writing Three.js to be
> ready for animation that I didn't think about this. If we restrict Three.js
> usage in Sage to static scenes then CPU usage drops to nothing.
>
> I'm happy to make this change, but this means no animations in the scenes
> for now.

What kind of animations are currently implemented?
I can only think of spin=[number].

 -- William

>
>
> On Saturday, December 3, 2016 at 1:11:31 PM UTC-8, Volker Braun wrote:
>>
>> Well if the scene is static, the controls didn't change, and the canvas
>> size didnt't change then your callback in requestAnimationFram should just
>> do nothing instead of repainting the unchanged scene, right?
>>
>>
>>
>> On Saturday, December 3, 2016 at 9:46:50 PM UTC+1, Paul Masson wrote:
>>>
>>>
>>>
>>> On Friday, December 2, 2016 at 11:47:40 PM UTC-8, tdumont wrote:


 But why is three.js consuming cpu when the browser shouls have nothing
 to do ? (no interaction).
>>>
>>>
>>> There is a rendering loop that runs continuously to call
>>> requestAnimationFram(). This is a standard technique for JavaScript
>>> animations in the browser.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.



-- 
William (http://wstein.org)

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: three.js on 7.5 beta 5: cpu...

2016-12-03 Thread Paul Masson
There's apparently no good way in general to test whether the scene is 
unchanged. This is a known issue:

https://github.com/mrdoob/three.js/issues/7670

One of the comments on this thread offers another option: only render the 
scene upon user interaction. I'm so accustomed to writing Three.js to be 
ready for animation that I didn't think about this. If we restrict Three.js 
usage in Sage to static scenes then CPU usage drops to nothing.

I'm happy to make this change, but this means no animations in the scenes 
for now.

On Saturday, December 3, 2016 at 1:11:31 PM UTC-8, Volker Braun wrote:
>
> Well if the scene is static, the controls didn't change, and the canvas 
> size didnt't change then your callback in requestAnimationFram should just 
> do nothing instead of repainting the unchanged scene, right?
>
>
>
> On Saturday, December 3, 2016 at 9:46:50 PM UTC+1, Paul Masson wrote:
>>
>>
>>
>> On Friday, December 2, 2016 at 11:47:40 PM UTC-8, tdumont wrote:
>>>
>>>
>>> But why is three.js consuming cpu when the browser shouls have nothing 
>>> to do ? (no interaction). 
>>>
>>
>> There is a rendering loop that runs continuously to call 
>> requestAnimationFram(). 
>> This is a standard technique for JavaScript animations in the browser. 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: three.js on 7.5 beta 5: cpu...

2016-12-03 Thread William Stein
On Sat, Dec 3, 2016 at 1:11 PM, Volker Braun  wrote:
> Well if the scene is static, the controls didn't change, and the canvas size
> didnt't change then your callback in requestAnimationFram should just do
> nothing instead of repainting the unchanged scene, right?

+1   -- I just checked and our three.js implementation for SMC doesn't
have this problem.It's definitely not a necessary "standard
technique for JavaScript animations in the browser" to burn CPU
needlessly.

 -- William


>
>
>
> On Saturday, December 3, 2016 at 9:46:50 PM UTC+1, Paul Masson wrote:
>>
>>
>>
>> On Friday, December 2, 2016 at 11:47:40 PM UTC-8, tdumont wrote:
>>>
>>>
>>> But why is three.js consuming cpu when the browser shouls have nothing
>>> to do ? (no interaction).
>>
>>
>> There is a rendering loop that runs continuously to call
>> requestAnimationFram(). This is a standard technique for JavaScript
>> animations in the browser.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.



-- 
William (http://wstein.org)

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: three.js on 7.5 beta 5: cpu...

2016-12-03 Thread Volker Braun
Well if the scene is static, the controls didn't change, and the canvas 
size didnt't change then your callback in requestAnimationFram should just 
do nothing instead of repainting the unchanged scene, right?



On Saturday, December 3, 2016 at 9:46:50 PM UTC+1, Paul Masson wrote:
>
>
>
> On Friday, December 2, 2016 at 11:47:40 PM UTC-8, tdumont wrote:
>>
>>
>> But why is three.js consuming cpu when the browser shouls have nothing 
>> to do ? (no interaction). 
>>
>
> There is a rendering loop that runs continuously to call 
> requestAnimationFram(). 
> This is a standard technique for JavaScript animations in the browser. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: three.js on 7.5 beta 5: cpu...

2016-12-03 Thread Paul Masson


On Friday, December 2, 2016 at 11:47:40 PM UTC-8, tdumont wrote:
>
>
> But why is three.js consuming cpu when the browser shouls have nothing 
> to do ? (no interaction). 
>

There is a rendering loop that runs continuously to call 
requestAnimationFram(). 
This is a standard technique for JavaScript animations in the browser. 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: three.js on 7.5 beta 5: cpu...

2016-12-02 Thread Thierry Dumont
Le 02/12/2016 à 23:43, Paul Masson a écrit :
> Three.js performance is highly dependent on how the browser interacts
> with available graphics hardware. Chrome is the browser of choice for
> Three.js developers, but Firefox has made great improvements in the last
> couple years. If you're using the latest version of Firefox, then the
> bottleneck will be the GPU on your machine: if the browser can't
> interact efficiently with the GPU then the CPU has to pick up the slack.
> 
I use the beta version (weekly update) of Firefox.

But why is three.js consuming cpu when the browser shouls have nothing
to do ? (no interaction).

Ok, this is not very important.
t.d.

> Rendering this scene in Firefox on my year-old Macbook Pro settles down
> to around 30% of total CPU load. By contrast, rendering this scene in
> Firefox on my slightly older Windows 10 machine with a better GPU
> settles down to about 2% of total CPU load.
> 
> Opening multiple browser windows with Three.js scenes on my Macbook will
> bring the machine to a crawl and this is simply a machine limitation. I
> was initially worried this would be a major problem for Sage notebooks
> but it turns out not to be, since the notebook is a single browser window.
> 
> On Friday, December 2, 2016 at 7:31:27 AM UTC-8, tdumont wrote:
> 
> I have just tried three.js in 7.5 beta 5, doing (as in the doc):
> 
> sage: sage: p1 = sphere(color='red', opacity='.5')
> : sage: p2 = sphere((-1,-1,1), color='cyan', opacity='.3')
> : sage: p3 = sphere((1,-1,-1), color='yellow', opacity='.7')
> : sage: show(p1 + p2 + p3, viewer='threejs')
> 
> My firefox is launched, and the result is nice !
> 
> But looking at the cpu consumption of firefox, I found that it takes
> between 60% and 89% of one processor cpu time, even when I look at the
> steady graphic (mouse pointer out of the window).
> 
> May be there is nothing to do (some loop...),  but this is quite much!
> 
> t.d.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to sage-devel+unsubscr...@googlegroups.com
> .
> To post to this group, send email to sage-devel@googlegroups.com
> .
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
<>

[sage-devel] Re: three.js on 7.5 beta 5: cpu...

2016-12-02 Thread Paul Masson
Three.js performance is highly dependent on how the browser interacts with 
available graphics hardware. Chrome is the browser of choice for Three.js 
developers, but Firefox has made great improvements in the last couple 
years. If you're using the latest version of Firefox, then the bottleneck 
will be the GPU on your machine: if the browser can't interact efficiently 
with the GPU then the CPU has to pick up the slack.

Rendering this scene in Firefox on my year-old Macbook Pro settles down to 
around 30% of total CPU load. By contrast, rendering this scene in Firefox 
on my slightly older Windows 10 machine with a better GPU settles down to 
about 2% of total CPU load.

Opening multiple browser windows with Three.js scenes on my Macbook will 
bring the machine to a crawl and this is simply a machine limitation. I was 
initially worried this would be a major problem for Sage notebooks but it 
turns out not to be, since the notebook is a single browser window.

On Friday, December 2, 2016 at 7:31:27 AM UTC-8, tdumont wrote:
>
> I have just tried three.js in 7.5 beta 5, doing (as in the doc): 
>
> sage: sage: p1 = sphere(color='red', opacity='.5') 
> : sage: p2 = sphere((-1,-1,1), color='cyan', opacity='.3') 
> : sage: p3 = sphere((1,-1,-1), color='yellow', opacity='.7') 
> : sage: show(p1 + p2 + p3, viewer='threejs') 
>
> My firefox is launched, and the result is nice ! 
>
> But looking at the cpu consumption of firefox, I found that it takes 
> between 60% and 89% of one processor cpu time, even when I look at the 
> steady graphic (mouse pointer out of the window). 
>
> May be there is nothing to do (some loop...),  but this is quite much! 
>
> t.d. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.