jit.gl.sketch dynamic changes in cmdlist


    Apr 23 2006 | 3:47 pm
    My turn to ask a question :)
    In the patch below I alter the position of 8 points of in a jit.gl.sketch. I do this using cmd_replace but this seems to be the cause of some slowing down when the changes are happening. Any hints on this ? Or is this the perfect case to start learning javascript and related jitter object...

    • Apr 23 2006 | 4:03 pm
      what happens if you change from pak to pack ?
      /*j
    • Apr 23 2006 | 4:27 pm
      Goes much better (probably 4x as much ;) ), still the occasional hiccup in the underlaying render but almost negligable. I've gotten so used to almost always using pak that I completely overlooked pack. Though it is just meant to add "sexyness" to an interface layer, i can do without when push comes to shove, but I'd rather not of course since it's those little details that add a lot to the experience.
      Thx Jasch.
    • Apr 23 2006 | 7:36 pm
      sorry for this double post. Don't know why that happened. Brought 'puter back from sleep and mail goes off re-sending mail.
    • May 02 2006 | 8:07 pm
      When implementing the cmdlist changes in a larger patch all worked fine. Now, when I open the patch on a PC, instead of Mac, the patch seems to crash on this. I have narrowed the problem down to the part where :
      a counter is activated when a certain logical condition is met. The counter runs up and changes 8 vertextpositions using the countervalue mapped onto the appropriate float values for the vertices.(using scale or zmap give the same result).
      When this process is set in motion, the vertices start moving and then stall. Resulting in a full stalling of max...
      Machine : AMD sempron 2500+ 1.75Ghz 512 Mb ram
      XP professinal, service pack 1
      NVIDIA GeForce3
      I haven't got the correct java version installed, which results in some error messages when starting up max, but I presume these are unrelated. I'm in no need for javasupport anyways.
      Could this be because of the nr. of cmd_replace messages sent?
      rgds, B.
    • May 03 2006 | 9:24 am
      Sounds like you are either backlogging the scheduler/queue (make sure you drive with qmetro rather than metro), or you are growind your cmd_list infinitely.
      -Joshua
    • May 03 2006 | 11:17 pm
      Alrighty.. I'll give it a go keeping that in mind. Only strange thing that strikes me, is that this problem does not occur under OS X with the same patch...
    • May 04 2006 | 1:01 am
      maybe run the patch and keep it open for a long time, like a few hours, and you can see if the patch begins to slow down, and check the cmd_list to see if , indeed, it has grown thus fucking things up? Might not explain the PC crash, but.. eh.. *shrug*
      its brute force, but hey..
      v a d e //
      www.vade.info abstrakt.vade.info
    • May 06 2006 | 1:05 am
      As suggested by Joshua, I've separated the cmdlist changes to be triggered by a qmetro. I haven't been able to check what exactly the problem was, but I suspect it was due to the fact that is was triggered by a logical operator, which in turn was triggered by, well, stuff happening continuously really... I guess the cmdlist didn't know how to handle this on windows... or on mac it was a bit more 'leeway'.