Programmable pipeline incompatible with Syphon

[codeanticode]

@vade, @bangnoise: If Processing initializes the GL context using a programmable pipeline (GL2ES2, GL2GL3, or getGL4ES3), then frames sent from a server in Processing are rendered as black (tested with simple client and MadMapper 2.0.1). Also running both the server and client from Processing, with a programmable pipeline, results in no image displayed by the client.

Is this a bug in Processing or Syphon?

[vade]

This is a known issue, currently processing supports only OpenGL 1.2 / 2.x contexts. @bangnoise and I are sorting out solutions / Core Profile inclusion at some point in the future.

What is the timeline for Processing to work with a Core Profile context by default? Is this new for Processing 3.0 ?

Somehow most Syphon apps are still leveraging 1.2 / 2.x contexts, so we haven't had the proverbial gun to our head to update.

Thanks, and sorry about that!

You can check out: Syphon/Syphon-Framework#13 and update there too with any new info.

[codeanticode]

Not sure if Core Profile context is used in the latest betas, but we switched to a programmable-pipeline already in beta 4, specifically GL2ES2, see processing/processing#3505.

This is the main reason why Syphon is not working in betas 4 and 5. In fact, you can choose what profile to use by doing:

void settings() {
  size(1280, 800, P2D);
  PGJOL.profile = 3;
}

So, I added back profile 1 (which means OpenGL 1.2 / 2.x context), and with that Syphon works again.

[vade]

Interesting.

Ok, that sort of lights a proverbial fire :)

Any idea when The release is scheduled, roughly?

Thanks again for all your hard work on Processing / Java and Syphon, its very appreciated!

[codeanticode]

Beta 5 is already the last stable Processing release available for download so anyone getting that version won't be able to use Syphon.

You could potentially use profile = 1 in beta 6, while Syphon updates to Core Profile. Once that happens, all you would need to do from Processing is to switch to a higher profile.

[bangnoise]

There are a couple of third-party core profile Syphon implementations - if
you think it makes more sense, you could use one of them until we catch up.
That might be preferable - but wouldn't work with profile = 1. They're
linked in the relevant issue on the Syphon Framework - travelling atm, or
I'd link you directly.

When we support Core Profile we won't drop legacy support, so eventually
you will be able to use the same framework with either/any.
On Tue, 1 Sep 2015 at 15:05 codeanticode [email protected] wrote:

Beta 5 is already the last stable Processing release available for
download https://processing.org/download/?processing so anyone getting
that version won't be able to use Syphon.

You could potentially use profile = 1 in beta 6, while Syphon updates to
Core Profile. Once that happens, all you would need to do from Processing
is to switch to a higher profile.

—
Reply to this email directly or view it on GitHub
#25 (comment).

[codeanticode]

cool, I will look at the options and decide what to do. This one:

https://github.com/eromanc/Syphon-Framework

seems the most recent fork. Any other one you recommend? However, I feel it would be easier to add support for profile = 1, and keep using the original Syphon.

[codeanticode]

Added profile = 1 to all examples, this solves the issue. Once Syphon adds support to Core Profile, switch from the library should only involve changing the profile value to 2 or higher.

[knupel]

With the PJOGL.profile = 1 the first picture is ok, but that's all. No animation. I'm on Processing 3.0b6 and the last Syphon, my computer is an iMac 2012 / OSX 10.9.5

[codeanticode]

The problem is that sendScreen() is not working, as reported here. This issue was about the incompatibility with the programmable pipeline, which is addressed by using profile = 1.

[knupel]

ok, oops sorry. I post here because I see the new line about the profile = 1.

[alexdmiller]

I realize this issue is old & closed, but I have a question: if I'm understanding this correctly, does this mean we can't use shaders and Syphon in the same Processing sketch? Switching to profile = 1 seems to break my GLSL code.

[vade]

Can you file a separate issue that actually details behaviour you expect and behavior you see along with details or your setup, versions, install, etc?

[alexdmiller]

Thanks @vade.

I figured out the problem: switching profiles meant that the GLSL code was compiled with a different version (version 110). I had texture calls that I had to switch to texture2D in order to compile under version 110.

I'm happy to file another issue if you think it's necessary, although it's not really a problem with this project. It might be helpful to include a note about GLSL versions in the readme, though. To someone unfamiliar with OpenGL and Processing internals, the PGJOL.profile = 1; line is completely opaque.