[PD] animation api

Thu Jan 7 17:52:49 CET 2016

Do you have a simple patch to test?
Not sure exactly what's going on, but I can think of three relevant areas:* node.js APIs are largely built to be asynchronous* V8 javascript engine does JIT compilation of hot code* Chromium goes out of its way to ensure that nothing blocks the renderer from doing its job
Of course advertisers don't have to pay for the CPU they consume on your device, which 
mean all browser-based technology are CPU hogs.
-Jonathan

    On Thursday, January 7, 2016 11:19 AM, Ivica Ico Bukvic <ico at vt.edu> wrote:

  Would you please test the same on pd-l2ork and/or vanilla? If there is a stark difference, this may suggest that node webkit does some kind of internal event pruning (which would be really sweet). Also, checking CPU overhead may help shed some light as to what is going on. Finally, what are the specs of your machine?

 On 1/7/2016 2:20 AM, Jonathan Wilkes wrote:

     In the GUI port I hooked up about 14 toggles to a [metro 1] and was getting 
  anywhere between 30 and 40 fps in the GUI.  I could continue creating new 
  objects in the same patch. 
  Now if I connected each of those toggles to a [print] I'd probably freeze the 
  GUI.  But I'm not doing any optimization on console, nor limiting the 
  size of the scrollback buffer.  (I am, however, displaying a hit count beside 
  duplicate messages which cuts down immensely on noise.) 
  At least for now, if some common patch behavior is able to DOS the 
  GUI I'd rather have it freeze up as an incentive to fix the underlying problem. 
  -Jonathan

         On Wednesday, January 6, 2016 1:07 PM, Ivica Bukvic <ico at vt.edu> wrote:

    Create a metronome with less than 2 milliseconds clock and connect it to a bunch of toggles, turn it on, and enjoy interacting with a  barely responsive gui. The same is achievable with a less dubious implementation where a graphical user interface simply has a lot of concurrently animated components. NB: depending on your computer specs the two millisecond threshold may have to be set lower. -- 
 Ivica Ico Bukvic, D.M.A.
 Associate Professor
 Computer Music
 ICAT Senior Fellow
 Director -- DISIS, L2Ork
 Virginia Tech
 School of Performing Arts – 0141
 Blacksburg, VA 24061
 (540) 231-6139
 ico at vt.edu
 www.performingarts.vt.edu
 disis.icat.vt.edu
 l2ork.icat.vt.edu
 ico.bukvic.net 

   On Jan 6, 2016 9:31 AM, "Jonathan Wilkes" <jancsika at yahoo.com> wrote:

        Are there more than two people (matju and Miller) who understand the 
  _current_ design? 
  -Jonathan

          On Wednesday, January 6, 2016 12:00 AM, Ivica Ico Bukvic <ico at vt.edu> wrote:

    The following is going somewhat OT but nonetheless based on this very interesting  topic: application framerate is no more deterministic than the proposed idea. Just because monitor refreshes at 60Hz doesn't mean the app will  do the same or consistently. Yet, pegging GUI updates at 60Hz (think speedlim-like behavior) despite all the loose ends will undoubtedly  provide improved responsiveness over a GUI where one can send  sub-millisecond change requests, most of which will never see the light of the day, despite eating up tons of CPU and in all likelihood  bringing it down to its knees.

  On 1/4/2016 9:32 PM, Jonathan Wilkes wrote:

        Having an animation method allows  GUI-side optimizations that aren't 
  possible when the animation is  smeared across the socket/parser/eval'er. 
  Determinism: GUI rendering isn't  deterministic, at least not in the way Pd's 
  scheduler is.  For example, how could the GUI  (tcl/tk or otherwise) even 
  know that it missed a deadline?

  I guess the simple API I'm toying  with is "stretching the accordion"  so to 
  speak, and potentially  showing the cracks more explicitly  with a longer 
  running animation than can currently  be seen in Pd's GUI.  But that can be 
  remedied, either by recursively  halving a single animation into  smaller ones, 
  or just giving up and using  [line].

  The greater benefit is  that more elegant types of visual  feedback become 
  possible without being discarded out  of hand due to their potential for 
  audio interruption. 
  -Jonathan

          On Monday, January 4,  2016 5:20 PM, Ivica Ico Bukvic <ico at vt.edu> wrote:

    On 1/3/2016 3:24 PM, Jonathan  Wilkes wrote:

     It's actually way more  simplistic than that-- just an  "animate" method that 
  wraps around whatever  attribute is available to the drawing  command.  All 
  I'll have is a ramp time, an  optional delay time, and an optional  easing curve. 
  That will make it a bit like a  [vline~] for GUI side animation. 
  I'm using the web animations API  because it makes things very simple, even 
  to do complex things like  animating path data. 
  The idea is that this would  open up some modest visualization  opportunities 
  that are otherwise too cpu  intensive.  For example, if you're  animating 
  using [line] the socket  messages can quickly get in the way of the  audio.

 Will you at some point  drown the CPU? Sure, but that is no  different than a million of  other ways of doing the same. OTOH,  implementing the animation  this way helps you ensure that your  animation remains in sync with the audio, which to me seems  much better gain than a potential  CPU/socket overhead may  be a shortcoming.

 There could be some very cool  ways of filtering gui messages, as  well (short of getting rid of  the socket-based communication  in favor of a shared  memory/multithreaded design). For instance, your  animation object could  be given the screen refresh rate and  therefore it would not send out a message via a socket unless a  desired frame-worth of time has  transpired since the last  message was sent. This would do  wonders not just in terms  of animation, but also the overall gui  responsiveness, if implemented  system-wide.

 Best,

 Ico 

  -Jonathan

    On Sunday, January 3,  2016 1:08 PM, Ivica Ico Bukvic <ico at vt.edu> wrote:

    I think it may make sense in  addition to having a one-shot-independent animations that have no  guarantee of staying in sync with the  audio (e.g. these could be  useful for mouse-over button  animations) that your animation object can also receive a  decimal value between its originator and destination, allowing for  each keyframe to be a whole number. So,  0-1 would interpolate  between the starting state and first  keyframe, 1-2 between first  and second keyframes, etc., and thus  allow pd to use its timing  mechanism to project changes in  animation state via a line object, a counter or something  similar. IIRC most (all?) HTML5-based  animations can be triggered  as independent events or can be given a  specific percentage  value. The one-shot object could  interact with independent events, while the proposed object could  interact with the latter.

 That said, not knowing how  you have imagined your animation  object, it may be tricky to  implement this as it would require object  to keep track of all the  keyframed events (assuming  there are more than one). If you are thinking of having the  animation object track only one  single animation (e.g. something progressing  from 30% to 90%), the same could still  prove useful except in this  case you would only allow for values between 0 and 1.

  On 1/2/2016 1:12 PM, Jonathan  Wilkes via Pd-list wrote:

  Hi list, I'm playing with adding a  simple animation api to data  structure drawing commands. 
  The parameters will be sent  to the GUI, and the GUI will take care  of the ramp, delay, etc. 
  I'm thinking of just making it  a simple "set it and forget it" api.  That is, you send a message 
  with your ramp and delay times to  the GUI, and you just blindly trust that the GUI will make 
  things happen in the right amount  of time.  The alternative I can think of  is to have the GUI 
  call back when an animation is  finished, but that would encourage  mixing the two clocks 
  (i.e., GUI and Pd clock) in  unpredictable 
  ways. 
  Does this simple approach seem  like a reasonable design?  The biggest problem would  be that 
  a long-running animation  could skew.  But in that case you could  probably amortize the cost of sending more messages over the  longer time period.

  -Jonathan

 _______________________________________________
Pd-list at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

 _______________________________________________
 Pd-list at lists.iem.at mailing list
 UNSUBSCRIBE and  account-management -> http://lists.puredata.info/listinfo/pd-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160107/e091d5a3/attachment-0001.html>