search

jaanga / gestification

Apps for the Leap Motion device. Demos here:
jaanga.github.io/gestification/
Other
59 stars 36 forks source link

Update boilerplate to throttle down data rate #2

Closed paulmasson closed 10 years ago

paulmasson commented 11 years ago

Instead of using the default Leap.loop(), create the controller manually and call it at a slower rate using setInterval(). Response is of course slower but when the hand is held still it doesn't bounce around wildly.

theo-armour commented 11 years ago

Paul

Pull Request Thank you for the pull request.

In the next day or so I will accept your request and then - most likely - override it.

In this way, your request will be noted for posterity.

setInterval and requestAnumationFrame The use of setInterval() has a slew of issues.

Have a look at:

https://developer.mozilla.org/en-US/docs/Web/API/window.requestAnimationFrame http://www.paulirish.com/2011/requestanimationframe-for-smart-animating/

Unfortunately neither of these articles give the full background as to why requestAnimationFrame (rAF)was built to circumvent setInterval() issues. But seek and ye shall find.

The most prevalent issue is what happens to a setInterval() when it (and other setIntervals) is embedded in one of a number of tabs that are no longer the front tab.

rAF takes care of that issue and much more. Again seek and ye shall find.

An interesting aspect is that both Leap and Three.js use rAF. I have tried combining the two calls into one. That got complicated. I have found that letting each makes it own call has had little downside.

Regarding Safari Wouldn't the Safari rAF issue be a good (much more appropriate) issue for http://bugreport.apple.com/‎ than for me?

Safari and IE are very nice browsers for people who use a stock system in a stock manner. Nothing wrong with that.

But I design for computers that will be standard several years in the future.

Not everybody does this. Some people get off on designing for Amigas or PDP-11s.

Since I do develop for tomorrow I tend to use tools - such browsers - that tend to be leading edge and simply ignore tools that are not.

I feel this helps in keeping both my code and my brain on the edgy side of things.

Most programmers - because they are employees of large organizations - have neither the freedom nor the edginess.

Given that I have have wherewithal to do whatever I want, I feel this predilection to search where others mostly cannot is a good use of my limited coding talents.

And I don't see that using my time to address Safari issues would be in any significant way beneficial.

ox ox

Theo

On Sat, Oct 26, 2013 at 10:45 PM, paulmasson notifications@github.comwrote:

Instead of using the default Leap.loop(), create the controller manually and call it at a slower rate using setInterval(). Response is of course

slower but when the hand is held still it doesn't bounce around wildly.

You can merge this Pull Request by running

git pull https://github.com/paulmasson/gestification gh-pages

Or view, comment on, or merge it at:

https://github.com/jaanga/gestification/pull/2 Commit Summary

  • Update boilerplate to throttle down data rate

File Changes

  • M cookbook/boilerplate/leap-threejs-boilerplate.htmlhttps://github.com/jaanga/gestification/pull/2/files#diff-0(16)

Patch Links:

paulmasson commented 11 years ago

Two quick questions:

I combined the two rAF loops with no problem on Firefox. What problems did you encounter?

If Safari and Chrome both use Webkit, why is the latter superior? The rendering process is precisely what is causing the Safari problem. What does Chrome add to the process that Safari does not? -----Original Message----- From: Theo Armour [mailto:notifications@github.com] Sent: Saturday, October 26, 2013 11:45 PM To: jaanga/gestification Cc: paulmasson Subject: Re: [gestification] Update boilerplate to throttle down data rate (#2)

Paul

Pull Request Thank you for the pull request.

In the next day or so I will accept your request and then - most likely - override it.

In this way, your request will be noted for posterity.

setInterval and requestAnumationFrame The use of setInterval() has a slew of issues.

Have a look at:

https://developer.mozilla.org/en-US/docs/Web/API/window.requestAnimationFrame http://www.paulirish.com/2011/requestanimationframe-for-smart-animating/

Unfortunately neither of these articles give the full background as to why requestAnimationFrame (rAF)was built to circumvent setInterval() issues. But seek and ye shall find.

The most prevalent issue is what happens to a setInterval() when it (and other setIntervals) is embedded in one of a number of tabs that are no longer the front tab.

rAF takes care of that issue and much more. Again seek and ye shall find.

An interesting aspect is that both Leap and Three.js use rAF. I have tried combining the two calls into one. That got complicated. I have found that letting each makes it own call has had little downside.

Regarding Safari Wouldn't the Safari rAF issue be a good (much more appropriate) issue for http://bugreport.apple.com/‎ than for me?

Safari and IE are very nice browsers for people who use a stock system in a stock manner. Nothing wrong with that.

But I design for computers that will be standard several years in the future.

Not everybody does this. Some people get off on designing for Amigas or PDP-11s.

Since I do develop for tomorrow I tend to use tools - such browsers - that tend to be leading edge and simply ignore tools that are not.

I feel this helps in keeping both my code and my brain on the edgy side of things.

Most programmers - because they are employees of large organizations - have neither the freedom nor the edginess.

Given that I have have wherewithal to do whatever I want, I feel this predilection to search where others mostly cannot is a good use of my limited coding talents.

And I don't see that using my time to address Safari issues would be in any significant way beneficial.

ox ox

Theo

On Sat, Oct 26, 2013 at 10:45 PM, paulmasson notifications@github.comwrote:

Instead of using the default Leap.loop(), create the controller manually and call it at a slower rate using setInterval(). Response is of course

slower but when the hand is held still it doesn't bounce around wildly.

You can merge this Pull Request by running

git pull https://github.com/paulmasson/gestification gh-pages

Or view, comment on, or merge it at:

https://github.com/jaanga/gestification/pull/2 Commit Summary

  • Update boilerplate to throttle down data rate

File Changes

  • M cookbook/boilerplate/leap-threejs-boilerplate.htmlhttps://github.com/jaanga/gestification/pull/2/files#diff-0(16)

Patch Links:

theo-armour commented 11 years ago

I combined the two rAF loops with no problem on Firefox. What problems did you encounter?

No real problems. Just complications. A number of them. For example, if you have some things loading for Three.js and some things loading with the Leap, then with a single rAF you must wait until both are complete before loading. With two, each can proceed when ready.

And, if I remember correctly, Leap only calls rAF when a hand is present and thus the Three.js parts freeze when a hand is not present and you cannot, for example, use a mouse to zoom, pan or orbit.

I also find this reminds of my experiences with combining jQuery with Three.js. These are two very different coding environments. What works for me is to wear my jQuery hat and think in jQuery. Later take the hat off and put on the Three.js hat and think in its way. And I do this by keeping the jQuery procedures and so on quite separate from the Three.js procedures.

Yes, communication is mostly by throwing things over the wall. But I have yet to see performance issues and debugging is easier as well.

If Safari and Chrome both use Webkit, why is the latter superior? The rendering process is precisely what is causing the Safari problem. What does Chrome add to the process that Safari does not?

http://thenextweb.com/google/2013/04/08/its-here-google-replaces-webkit-with-blink-in-latest-build-of-chrome/ http://techcrunch.com/2013/05/16/google-has-already-removed-8-8m-lines-of-webkit-code-from-blink/

But that does not really answer your question as I happily used rAF on Chrome (and FF) for many many months prior to the Google switch.

Again, Apple bug reports would be the place for informed views/discussion on the topic. This is way above my brain grade.

Theo

On Sun, Oct 27, 2013 at 2:50 PM, paulmasson notifications@github.comwrote:

Two quick questions:

I combined the two rAF loops with no problem on Firefox. What problems did you encounter?

If Safari and Chrome both use Webkit, why is the latter superior? The rendering process is precisely what is causing the Safari problem. What does Chrome add to the process that Safari does not? -----Original Message----- From: Theo Armour [mailto:notifications@github.com] Sent: Saturday, October 26, 2013 11:45 PM To: jaanga/gestification Cc: paulmasson Subject: Re: [gestification] Update boilerplate to throttle down data rate (#2)

Paul

Pull Request Thank you for the pull request.

In the next day or so I will accept your request and then - most likely - override it.

In this way, your request will be noted for posterity.

setInterval and requestAnumationFrame The use of setInterval() has a slew of issues.

Have a look at:

https://developer.mozilla.org/en-US/docs/Web/API/window.requestAnimationFrame http://www.paulirish.com/2011/requestanimationframe-for-smart-animating/

Unfortunately neither of these articles give the full background as to why requestAnimationFrame (rAF)was built to circumvent setInterval() issues. But seek and ye shall find.

The most prevalent issue is what happens to a setInterval() when it (and other setIntervals) is embedded in one of a number of tabs that are no longer the front tab.

rAF takes care of that issue and much more. Again seek and ye shall find.

An interesting aspect is that both Leap and Three.js use rAF. I have tried combining the two calls into one. That got complicated. I have found that letting each makes it own call has had little downside.

Regarding Safari Wouldn't the Safari rAF issue be a good (much more appropriate) issue for http://bugreport.apple.com/‎ than for me?

Safari and IE are very nice browsers for people who use a stock system in a stock manner. Nothing wrong with that.

But I design for computers that will be standard several years in the future.

Not everybody does this. Some people get off on designing for Amigas or PDP-11s.

Since I do develop for tomorrow I tend to use tools - such browsers - that tend to be leading edge and simply ignore tools that are not.

I feel this helps in keeping both my code and my brain on the edgy side of things.

Most programmers - because they are employees of large organizations - have neither the freedom nor the edginess.

Given that I have have wherewithal to do whatever I want, I feel this predilection to search where others mostly cannot is a good use of my limited coding talents.

And I don't see that using my time to address Safari issues would be in any significant way beneficial.

ox ox

Theo

On Sat, Oct 26, 2013 at 10:45 PM, paulmasson notifications@github.comwrote:

Instead of using the default Leap.loop(), create the controller manually and call it at a slower rate using setInterval(). Response is of course

slower but when the hand is held still it doesn't bounce around wildly.

You can merge this Pull Request by running

git pull https://github.com/paulmasson/gestification gh-pages

Or view, comment on, or merge it at:

https://github.com/jaanga/gestification/pull/2 Commit Summary

  • Update boilerplate to throttle down data rate

File Changes

Patch Links:

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/jaanga/gestification/pull/2#issuecomment-27180307 .

paulmasson commented 11 years ago

My testing yesterday showed that the Leap controller is continuously calling at the same time as your animation loop, with or without hands present. It's kind of amazing that this setup works at all. -----Original Message----- From: Theo Armour [mailto:notifications@github.com] Sent: Sunday, October 27, 2013 3:36 PM To: jaanga/gestification Cc: paulmasson Subject: Re: [gestification] Update boilerplate to throttle down data rate (#2)

I combined the two rAF loops with no problem on Firefox. What problems did you encounter?

No real problems. Just complications. A number of them. For example, if you have some things loading for Three.js and some things loading with the Leap, then with a single rAF you must wait until both are complete before loading. With two, each can proceed when ready.

And, if I remember correctly, Leap only calls rAF when a hand is present and thus the Three.js parts freeze when a hand is not present and you cannot, for example, use a mouse to zoom, pan or orbit.

I also find this reminds of my experiences with combining jQuery with Three.js. These are two very different coding environments. What works for me is to wear my jQuery hat and think in jQuery. Later take the hat off and put on the Three.js hat and think in its way. And I do this by keeping the jQuery procedures and so on quite separate from the Three.js procedures.

Yes, communication is mostly by throwing things over the wall. But I have yet to see performance issues and debugging is easier as well.

If Safari and Chrome both use Webkit, why is the latter superior? The rendering process is precisely what is causing the Safari problem. What does Chrome add to the process that Safari does not?

http://thenextweb.com/google/2013/04/08/its-here-google-replaces-webkit-with-blink-in-latest-build-of-chrome/ http://techcrunch.com/2013/05/16/google-has-already-removed-8-8m-lines-of-webkit-code-from-blink/

But that does not really answer your question as I happily used rAF on Chrome (and FF) for many many months prior to the Google switch.

Again, Apple bug reports would be the place for informed views/discussion on the topic. This is way above my brain grade.

Theo

On Sun, Oct 27, 2013 at 2:50 PM, paulmasson notifications@github.comwrote:

Two quick questions:

I combined the two rAF loops with no problem on Firefox. What problems did you encounter?

If Safari and Chrome both use Webkit, why is the latter superior? The rendering process is precisely what is causing the Safari problem. What does Chrome add to the process that Safari does not? -----Original Message----- From: Theo Armour [mailto:notifications@github.com] Sent: Saturday, October 26, 2013 11:45 PM To: jaanga/gestification Cc: paulmasson Subject: Re: [gestification] Update boilerplate to throttle down data rate (#2)

Paul

Pull Request Thank you for the pull request.

In the next day or so I will accept your request and then - most likely - override it.

In this way, your request will be noted for posterity.

setInterval and requestAnumationFrame The use of setInterval() has a slew of issues.

Have a look at:

https://developer.mozilla.org/en-US/docs/Web/API/window.requestAnimationFrame http://www.paulirish.com/2011/requestanimationframe-for-smart-animating/

Unfortunately neither of these articles give the full background as to why requestAnimationFrame (rAF)was built to circumvent setInterval() issues. But seek and ye shall find.

The most prevalent issue is what happens to a setInterval() when it (and other setIntervals) is embedded in one of a number of tabs that are no longer the front tab.

rAF takes care of that issue and much more. Again seek and ye shall find.

An interesting aspect is that both Leap and Three.js use rAF. I have tried combining the two calls into one. That got complicated. I have found that letting each makes it own call has had little downside.

Regarding Safari Wouldn't the Safari rAF issue be a good (much more appropriate) issue for http://bugreport.apple.com/‎ than for me?

Safari and IE are very nice browsers for people who use a stock system in a stock manner. Nothing wrong with that.

But I design for computers that will be standard several years in the future.

Not everybody does this. Some people get off on designing for Amigas or PDP-11s.

Since I do develop for tomorrow I tend to use tools - such browsers - that tend to be leading edge and simply ignore tools that are not.

I feel this helps in keeping both my code and my brain on the edgy side of things.

Most programmers - because they are employees of large organizations - have neither the freedom nor the edginess.

Given that I have have wherewithal to do whatever I want, I feel this predilection to search where others mostly cannot is a good use of my limited coding talents.

And I don't see that using my time to address Safari issues would be in any significant way beneficial.

ox ox

Theo

On Sat, Oct 26, 2013 at 10:45 PM, paulmasson notifications@github.comwrote:

Instead of using the default Leap.loop(), create the controller manually and call it at a slower rate using setInterval(). Response is of course

slower but when the hand is held still it doesn't bounce around wildly.

You can merge this Pull Request by running

git pull https://github.com/paulmasson/gestification gh-pages

Or view, comment on, or merge it at:

https://github.com/jaanga/gestification/pull/2 Commit Summary

  • Update boilerplate to throttle down data rate

File Changes

Patch Links:

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/jaanga/gestification/pull/2#issuecomment-27180307 .

— Reply to this email directly or view it on GitHub.

theo-armour commented 11 years ago

BTW, see

https://github.com/leapmotion/leapjs/blob/master/leap.js#L6864-6874

My testing yesterday showed that the Leap controller is continuously calling at the same time as your animation loop, with or without hands present. It's kind of amazing that this setup works at all.

And, if I remember correctly, Leap only calls rAF when a hand is present

See also: https://github.com/leapmotion/leapjs/blob/master/leap.js#L273-278

if (this.connection.connect() && this.inBrowser() && !controller. suppressAnimationLoop) {

I may have run across one of these conditions.

It's kind of amazing that this setup works at all.

At first glance yes.

But then think of the average dingbat with thirty seven tabs open and many of those with iframes open. There can be dozens of rAF's happening in the system. The browser better be able to deal with this.

On Sun, Oct 27, 2013 at 4:23 PM, paulmasson notifications@github.comwrote:

My testing yesterday showed that the Leap controller is continuously calling at the same time as your animation loop, with or without hands present. It's kind of amazing that this setup works at all. -----Original Message----- From: Theo Armour [mailto:notifications@github.com] Sent: Sunday, October 27, 2013 3:36 PM To: jaanga/gestification Cc: paulmasson Subject: Re: [gestification] Update boilerplate to throttle down data rate (#2)

I combined the two rAF loops with no problem on Firefox. What problems did you encounter?

No real problems. Just complications. A number of them. For example, if you have some things loading for Three.js and some things loading with the Leap, then with a single rAF you must wait until both are complete before loading. With two, each can proceed when ready.

And, if I remember correctly, Leap only calls rAF when a hand is present and thus the Three.js parts freeze when a hand is not present and you cannot, for example, use a mouse to zoom, pan or orbit.

I also find this reminds of my experiences with combining jQuery with Three.js. These are two very different coding environments. What works for me is to wear my jQuery hat and think in jQuery. Later take the hat off and put on the Three.js hat and think in its way. And I do this by keeping the jQuery procedures and so on quite separate from the Three.js procedures.

Yes, communication is mostly by throwing things over the wall. But I have yet to see performance issues and debugging is easier as well.

If Safari and Chrome both use Webkit, why is the latter superior? The rendering process is precisely what is causing the Safari problem. What does Chrome add to the process that Safari does not?

http://thenextweb.com/google/2013/04/08/its-here-google-replaces-webkit-with-blink-in-latest-build-of-chrome/

http://techcrunch.com/2013/05/16/google-has-already-removed-8-8m-lines-of-webkit-code-from-blink/

But that does not really answer your question as I happily used rAF on Chrome (and FF) for many many months prior to the Google switch.

Again, Apple bug reports would be the place for informed views/discussion on the topic. This is way above my brain grade.

Theo

On Sun, Oct 27, 2013 at 2:50 PM, paulmasson notifications@github.comwrote:

Two quick questions:

I combined the two rAF loops with no problem on Firefox. What problems did you encounter?

If Safari and Chrome both use Webkit, why is the latter superior? The rendering process is precisely what is causing the Safari problem. What does Chrome add to the process that Safari does not? -----Original Message----- From: Theo Armour [mailto:notifications@github.com] Sent: Saturday, October 26, 2013 11:45 PM To: jaanga/gestification Cc: paulmasson Subject: Re: [gestification] Update boilerplate to throttle down data rate (#2)

Paul

Pull Request Thank you for the pull request.

In the next day or so I will accept your request and then - most likely

override it.

In this way, your request will be noted for posterity.

setInterval and requestAnumationFrame The use of setInterval() has a slew of issues.

Have a look at:

https://developer.mozilla.org/en-US/docs/Web/API/window.requestAnimationFrame http://www.paulirish.com/2011/requestanimationframe-for-smart-animating/

Unfortunately neither of these articles give the full background as to why requestAnimationFrame (rAF)was built to circumvent setInterval() issues. But seek and ye shall find.

The most prevalent issue is what happens to a setInterval() when it (and other setIntervals) is embedded in one of a number of tabs that are no longer the front tab.

rAF takes care of that issue and much more. Again seek and ye shall find.

An interesting aspect is that both Leap and Three.js use rAF. I have tried combining the two calls into one. That got complicated. I have found that letting each makes it own call has had little downside.

Regarding Safari Wouldn't the Safari rAF issue be a good (much more appropriate) issue for http://bugreport.apple.com/‎ than for me?

Safari and IE are very nice browsers for people who use a stock system in a stock manner. Nothing wrong with that.

But I design for computers that will be standard several years in the future.

Not everybody does this. Some people get off on designing for Amigas or PDP-11s.

Since I do develop for tomorrow I tend to use tools - such browsers - that tend to be leading edge and simply ignore tools that are not.

I feel this helps in keeping both my code and my brain on the edgy side of things.

Most programmers - because they are employees of large organizations - have neither the freedom nor the edginess.

Given that I have have wherewithal to do whatever I want, I feel this predilection to search where others mostly cannot is a good use of my limited coding talents.

And I don't see that using my time to address Safari issues would be in any significant way beneficial.

ox ox

Theo

On Sat, Oct 26, 2013 at 10:45 PM, paulmasson notifications@github.comwrote:

Instead of using the default Leap.loop(), create the controller manually and call it at a slower rate using setInterval(). Response is of course slower but when the hand is held still it doesn't bounce around

wildly.

You can merge this Pull Request by running

git pull https://github.com/paulmasson/gestification gh-pages

Or view, comment on, or merge it at:

https://github.com/jaanga/gestification/pull/2 Commit Summary

  • Update boilerplate to throttle down data rate

File Changes

Patch Links:

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub< https://github.com/jaanga/gestification/pull/2#issuecomment-27180307> .

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/jaanga/gestification/pull/2#issuecomment-27182402 .