Prevent Processing from opening a Frame

Hi everybody,

I'm rendering everything of my sketch to offscreen buffers and am sending those via Syphon to another application. I want to gain some more performance by preventing Processing from creating/opening a window, as it's just a black screen. Does anybody know if and how this could be accomplished?

Thanks for any tips Marcel :--)

Answers

  • no :)

    I can only hide the bar, not the frame. Don't know why. Sure someone else comes up with a better answer then me :) Do you do anything on the main frame? If you don't use background(0) or anything it should not be a issue.

    Also you don't need to draw on a offscreen bugger. You could also send 'g' with syphon.

  • Processing consists of a couple different things:

    It's an editor that allows you to write and run Processing without worrying about what's going on under the hood. Among other things, this editor creates a frame for you.

    You can also use Processing as a Java library, which gives you access to what's going on under the hood. You have to create your own frame, or you can do what you described and not use a frame at all.

    The answer is to just use Processing like you would any other Java library, and write Java code that does the sending of the offscreen buffers.

  • edited January 2015

    I'm not drawing anything to the main canvas. It's actually possible to hide it, but that makes the draw loop not being called and processed anymore.

    frame.setVisible( false );

    I might need to digg deeper...

    @Doeke: I'm not sure but rather convinced that rendering to screen instead of an offscreen buffer makes the application run slower, if I'm not rendering in Processing anyhow.

  • To do this, you need to use Processing as a Java library. What about my answer wasn't clear?

  • "I'm not drawing anything to the main canvas."
    Then it should not slow down anything, no? No need to hide anything.

  • edited January 2015

    @KevinWorkman: Nothing about your answer was clear. I am already using Processing in the fashion you're saying but as you had nothing to add regarding how I can hide the frame, I had nothing to say to your post. I would be happy if you knew how to solve my problem.

    @PhiLho: There is actually a difference in performance when I'm having a blank canvas of size 1x1 in comparison to 1000x1000. And I'm talking about a drop from 60fps to 40fps, which is actually significant. But I agree to that degree that I prolly won't gain another 20fps when not creating an actual frame.

  • I suppose Processing still draws the gray background at the given framerate (perhaps the double buffering mechanism), that would explain the difference of speed you mention. Indeed, making a small window should fix most of it (isn't the min size something like 100x100?).

  • edited January 2015

    Yeah the frame is 100x100, but the "canvas" inside that frame is only 1 pixel :-P

  • How are you already using Processing as a Java library? Can you post an MCVE?

    If you are indeed using it like I'm describing, then there is no frame created by default. You'd have to create it yourself.

    I suspect that you aren't really using Processing as a Java library.

  • @KevinWorkman

    Since which version is that? Cause I use 2.0.4 in IntelliJ and I don't have to create the frame either.

  • edited January 2015

    For clarification: Using Processing as a library

    If you are using the Processing development environment (PDE) to create your sketch then you are not using Processing as a library because the sketch created is based on the PApplet class which gives you the frame.

    If you are using another IDE such as Eclipse or IntelliJ and are have add Processing's core.jar to the classpath and you are not using the PApplet class then it is being used as a library.

    @clankill3r that should answer your question as well.

  • Ah I get it.

    But I was extending PApplet :)

  • What quark said.

    You can use Processing as a library, without hooking into any of the PApplet stuff. Just call whichever parts of the library you need (in your case, probably PGraphics?), and leave out any of the stuff that creates a frame for you.

  • If it works (not even sure if it does...), you loose a number of functions and advantages offered by PApplet, including animation and such.

  • edited January 2015

    Processing's PApplet is pretty useless w/o it being properly instantiated by its runSketch().
    If you wanna use PApplet and not having its canvas visible, simply never let setup() finish until your sketch ends!

  • smart one GTL!

  • Well extending PApplet is essential to using Processing's drawing functions, too, isn't it. Without it you're not able to load shaders and not even call the holy random() function.

    I tried

    while( true ) { }

    at the end of my setup(), but that doesn't prevent the frame to be created and displayed.

  • edited January 2015

    at the end of my setup(), but that doesn't prevent the frame to be created and displayed.

    JFrame is created along PApplet's instantiation within runSketch() before setup().
    But isn't displayed until setup() has finished. Dunno why that's not your case! :-/

    void setup() {
      size(300, 200, JAVA2D);
      frameRate(10);
      for (;; delay(1000)); // comment this out so canvas shows up!
    }
    
    void draw() {
      background((color) random(#000000));
    }
    

    P.S.: That only works w/ JAVA2D renderer! OpenGL 1s, like P2D & P3D, display canvas even in setup()! :-&
    Insert frame.setVisible(false); before infinite loop. It still shows up, but only for 1 second or so.

  • edited January 2015

    Cheers for the experimentation, but in your example the draw function doesn't seem to be executed. Try putting a println() in there, it won't get called.

    Actually, already calling

    frame.setVisible( false );

    without the infinite loop prevents the draw loop.

  • edited January 2015

    ... but in your example the draw function doesn't seem to be executed.

    I believe you've missed the comment right beside line #4: ~:>
    // comment this out so canvas shows up!

    It wasn't supposed to reach draw() anyways, since you wanna avoid its slowdown.
    The idea is to call another function w/ an infinite loop similar to draw()'s.

  • Ah, got it! 8-}

    This actually seems to work. Though I'm using some other libraries that seem to depend on the draw loop, damn. Cheers anyhow :-c

Sign In or Register to comment.