Howdy, Stranger!

We are about to switch to a new forum software. Until then we have removed the registration on this forum.

  • Multithreading Madness

    It could be eased a little by using 1 color variable instead of 3 separate r,g,b!

    I agree. However, the whole problem is that we can't use the color() function to create an instance of color. You could also roll it up into a single int or hexcode.

    What if there was more than 1 DataProcess instance. And all of them invoking Element's update() method at the same time?

    It is my understanding (assumption) that only one thread (DataProcess) will access any particular Element's update() function. Once we start talking about threading, there are all kinds of what-ifs we could run through, but I think OP's approach has only one Thread accessing any particular Element's update() function.

    The saner approach is for each Thread to have its own PGraphics object!

    I don't disagree. But again, the problem is that we can't use the PGraphics.color() function, apparently due to a bug in Processing's parser.

    The only problem would be to synchronize the time to render all those PGraphics to the main canvas!

    Would you really need to do that though? All we need the PGraphics for is to call the color() function. We don't actually have to draw to the PGraphics instance.

  • Multithreading Madness

    IMO, the approach above is faulty!
    It could be eased a little by using 1 color variable instead of 3 separate r,g,b!

    What if there was more than 1 DataProcess instance.
    And all of them invoking Element's update() method at the same time?
    That would scramble all of those r,g,b fields for sure! >:)

    The saner approach is for each Thread to have its own PGraphics object!
    That way there'd be neither corruption states nor performance bottlenecks! *-:)

    The only problem would be to synchronize the time to render all those PGraphics to the main canvas! 8-|

  • Multithreading Madness

    For synchronization, you'd have to synchronize (on some lock) around anything accessing the same state, in this case the calls to background() and color(). Something like this:

    Object lock = new Object();
    
    void setup() {
      size(200, 200);
    
      new MyThread().start();
    }
    
    void draw() {
      synchronized(lock) {
        background(0);
      }
    }
    
    class MyThread extends Thread {
    
      public void run() {
        while (true) {
    
          float r = random(255);
          float g = random(255);
          float b = random(255);
    
          synchronized(lock) {
            color(r, g, b);
          }
    
    
          try {
            //change this to a 1 for the problem to go away
            Thread.sleep(0);
          }
          catch(InterruptedException e) {
            e.printStackTrace();
          }
        }
      }
    }
    

    This seems to fix the problem, but depending on your real use case, it negates any benefits that threading gives you. But like PhiLho said, I'm not sure this is a great use of threading in the first place.

  • code edicute - proper structor or gudelines

    By convention, for functions/methods, names are next to their parens w/o any spaces between them: function(). :-B
    On the other hand, when it's a language keyword, like if, for, while, do, switch, catch, synchronize, etc.,
    a space is placed between that and its parens: if (), switch (), etc., in order to differentiate them
    from their regular function/method counterparts! :P

  • avoid ConcurrentModificationException

    I already fixed it by not using synchronize :) (I hope so, i need to test it with a beamer and a webcam today if i'm right)

  • avoid ConcurrentModificationException

    I tried synchronize, damn it's slow :)

  • avoid ConcurrentModificationException

    "Is that assumption wrong?"
    Don't assume, measure! ;-)

    synchronize is indeed slower than no synch, but you must worry only if the slow down is significant for your usage.

  • Framebuffer error loading images in OPENGL renderer

    We dunno your whole program yet. And the situation you're in is that you've got your code running in 2 threads at the same time:

    1. "Animation" thread: the main Processing's executing Thread.
    2. "MIDI" thread: the other 1 run by the MIDI library when invoking noteOn().

    My knowledge w/ threads is still intermediary. So I'll just try to guess what might be going on!

    Your field variable imgs[] is being accessed by both threads:

    • I believe in draw(), which is run by the "Animation" thread, the imgs[] are rendered w/ image().
    • While at the same time in colorImage(), run by "MIDI" thread, the pixels[] from imgs[] are merciless manipulated!
    • Also, updatePixels() is something to consider too!

    Maybe you should synchronize those critical parts in order to disallow concurrent access by 2 threads at the same time! >-)

  • Parallel threads with web requests slower then one thread??

    I guess you meant something like the following: It's reacting instantly in both cases.

    Now I'm getting what your point was. You should never ever do something like while(boolean) { } at all. Busy waits will slow down your whole program and effectively use a cached copy of the global boolean you think they are using. Using the keyword volatile fixes this behavior. Of course, having another thread accessing the same variable will slow down your current thread, but this should still outperform any attempt to give each step a copy of this variable and synchronize both.

    Just replacing line 14 with if(isActive) background((color)random(#000000)); proves that isActive is actually changed and the busy wait is using it's own copy of the variable.

  • How to get more control of external cameras?

    Hi, I think these two other threads in the new forum are relevant to your question:

    http://forum.processing.org/two/discussion/comment/2864

    http://forum.processing.org/two/discussion/968

    because a problem people are repeatedly facing with the built-in video library is how to access capture devices other than webcams and the like. Unfortunately, the solution is not easy at this moment because it would require a major update of the video library, and I don't have much time to work on it right now. Maybe javacv is an option since it wraps several libraries for video capture. A quick search online suggests that accessing an SLR camera directly through opencv is possible (this this for example), so perhaps the new processing-opencv library could allow you to do that through Processing, although I'm not sure.

  • JIT / loading time and need of clearing Image cache[SOLVED]

    Hello, friends :)

    I just found out that the forum is not zoho hosted anymore. Anyway, here's the deal:

    I'm creating a simple adventure game, so far so good but, when starting the game, it runs a little slow, I guess due to JIT – please correct me if I'm wrong. Therefore, I want to implement a loading screen before allowing the player to take over the control. I can figure out how to create a loading based in some time interval, but,

    is it possible to synchronize the loading time with the time JIT will take to allocate all the content in the memory, compile/etc (don't really know how it works)?

    Since it will be different in different machines, I would like to have it done properly, not based in some fixed time. I'm sorry if it has been asked before but, searching the forums, I didn't found the answer. Thank you in advance!