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
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
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:
> >
> >
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:
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
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 --
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
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
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
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
10 matches
Mail list logo