JDK 11.0.7+ shows blank screen with P2D and P3D on macOS (workaround)

[processing-bot]

Created by: sampottinger

Rendering is blank. Continuation of #123 / #121.

[processing-bot]

Created by: sampottinger

Hey @benfry! Sorry if this is a duplicate but the latest JOGL RC (the same one in use in Processing) does render correctly on a Mac with 11.0.8. I'll turn my attention to within our codebase to see what we can do.

[processing-bot]

Created by: benfry

Aha… well, also certainly possible that I broke something else while fiddling around…

[processing-bot]

Created by: benfry

i.e. the changes for disabling awt… (#55)

[processing-bot]

Created by: sampottinger

Thanks Ben! I'll review #55. Been digging around and haven't quite sorted it yet... Will keep you updated though

[processing-bot]

Created by: sampottinger

Looks like there may be an issue in JOGL's GLWindow (within PSurfaceJOGL). Replacing it with plain Swing plus JOGL's GLCanvas causes drawing to work properly again. Not sure yet what caused it based on a cursory review of the changelogs but something funky is going on because GLWindow works in standalone but invocation within Processing causes the rendering not to display. There's a lot in there though so I understand why a gap might exist between standalone invocation and what we are seeing in Processing. It would be nice not to do too much modification in PSurfaceJOGL but curious what your reaction is to moving to JFrame @benfry.

[processing-bot]

Created by: sampottinger

Just a quick summary of what I've set up here... Mac 10.14.6. Screenshot down below.

Here's the sketch code:

void setup() {
  size(640, 360, P3D);
  println(System.getProperty("java.version"));
}

void draw() {
  background(0);
  
  camera(
    mouseX,
    height/2,
    (height/2) / tan(PI/6),
    width/2,
    height/2,
    0,
    0,
    1,
    0
  );
  
  translate(width/2, height/2, -100);
  stroke(255);
  noFill();
  box(200);
}

I modified PSurfaceJOGL with the following:

  public void initFrame(PApplet sketch) {
    this.sketch = sketch;

    initIcons();
    initDisplay();
    initGL();
    initWindow();
    initListeners();
    initAnimator();

    // Create profile
    GLProfile profile = GLProfile.get(GLProfile.GL2);
    GLCapabilities capabilities = new GLCapabilities(profile);

    // Try JFrame
    JFrame otherWindowFrame = new JFrame("Test with JFrame");

    GLCanvas glcanvas = new GLCanvas(capabilities);
    glcanvas.addGLEventListener(createTestEventListener());
    glcanvas.setSize(400, 400);

    otherWindowFrame.getContentPane().add(glcanvas);
    otherWindowFrame.setSize(
        otherWindowFrame.getContentPane().getPreferredSize()
    );
    otherWindowFrame.setVisible(true);

    // Try GLWindow
    GLWindow otherWindowGl = GLWindow.create(capabilities);
    otherWindowGl.addGLEventListener(createTestEventListener());
    otherWindowGl.setTitle("Test with GLWindow");
    otherWindowGl.setSize(400, 400);
    otherWindowGl.setVisible(true);
  }

[processing-bot]

Created by: sampottinger

Well... heck.

Alright, so, it's hard to say exactly what about Processing is causing an issue for GLWindow and I just found that it's not 100% consistent that it will break (probably worse). Either way, there's something bad happening in NEWT + JDK 11.0.7 in Processing but not in standalone demos (which makes it hard to report a bug). We can do this switch to JFrame but, while com.jogamp.newt is a similar interface to a lot of stuff in Swing / AWT, it's not exactly the same. So, that's not a massive edit but it's also not small edit.

Pros for replacing NEWT with Swing:

• Resolves JDK 11.0.7+ shows blank screen with P2D and P3D on macOS (workaround) #124.
• Let's us lean on a lot of existing logic in PSurfaceAWT so less logic to maintain.
• Pushes more of the burden on Swing from NEWT/JOGL where the former is within the JDK itself.
• Edits entirely within Processing code base.

Cons for replacing NEWT with Swing:

• If anyone is reaching into PSurfaceJOGL's window, they may need to use its canvas instead and switch com.jogamp.newt.event for java.awt.event.
• There's probably some knowledge embedded in the current PSurfaceJOGL including the choice of GLWindow instead of JFrame + GLCanvas that could be lost by a change.
• Strong P3D dependency on AWT.

A practical consideration:
Of course, if we don't go with JFrame, I haven't yet seen a clear articulation of this issue on JOGL's side or in the JDK changelog that seems to account for this change so we would be in the business of plumbing into NEWT's source to try to find this. It's also possible that, if we do find the problem, the solution might not be accepted upstream.

On AWT in P3D
I know we are trying to keep AWT somewhat encapsulated so tying JFrame into PSurfaceJOGL may feel a bit odd. I wouldn't be proposing this if it weren't for the bug. Still, I think my argument for JFrame is that, given that JOGL inside AWT is a primary path for the library, there's currently no clear reason to carry NEWT if AWT achieves feature parity. AWT is already a dependency for that mode just like it is for P2D b/c NEWT needs things like AWT's GraphicsDevice given our current set up. Also, if we are in the position of not wanting to have AWT, there's a reasonable chance we wouldn't be using JOGL anyway. In fact, removing NEWT reduces our risk moving forward because we are already dependent on AWT elsewhere and NEWT's capabilities are arguably redundant to AWT in that case.

[processing-bot]

Created by: sampottinger

Started a proposal at #126.

[processing-bot]

Created by: sampottinger

Hey there @benfry... So, still working on a few things (like fullscreen) but I got a working version with JFrame! I'm also happy to report that it reduces amount of logic through re-use from PSurfaceAWT. I need to check but JEP 263 might have also cut down a bit on what's needed. Anyway, that's over at #126. Demo below. Just LMK if this direction is OK.

[processing-bot]

Created by: benfry

Yeah, unfortunately the JFrame route is a step backwards—we did a ton of work to get away from that so that we could get more consistent rendering performance. As soon as AWT is involved it's impossible to do stutter-free GL, so moving to NEWT was an important step to getting reliable performance. (Further, depending on how Swing is being used, it's sometimes simply copying the GL buffer into AWT which is super compatible but also cuts performance badly.)

@codeanticode might have thoughts; we may need to require the --disable-awt thing earlier than expected, along with -XStartOnFirstThread. Though most likely, there's some sort of AWT thing triggering (i.e. running GL calls from the wrong thread) that's causing trouble.

[processing-bot]

Created by: sampottinger

Ah that’s a shame. Just to be clear, I think the problem is in NEWT itself. Could you say more about why you think —disable-awt and -XStartOnFirstThread would help? Or are you hoping to jump to LWJGL right away?

On Aug 22, 2020, at 8:34 AM, Ben Fry [email protected] wrote:


Yeah, unfortunately the JFrame route is a step backwards—we did a ton of work to get away from that so that we could get more consistent rendering performance. As soon as AWT is involved it's impossible to do stutter-free GL, so moving to NEWT was an important step to getting reliable performance. (Further, depending on how Swing is being used, it's sometimes simply copying the GL buffer into AWT which is super compatible but also cuts performance badly.)

@codeanticode might have thoughts; we may need to require the --disable-awt thing earlier than expected, along with -XStartOnFirstThread. Though most likely, there's some sort of AWT thing triggering (i.e. running GL calls from the wrong thread) that's causing trouble.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[processing-bot]

Created by: sampottinger

Also let me know @benfry and @codeanticode if there’s anything I can do to help. I’ll pause for now though.

[processing-bot]

unassigned @processing-bot

[processing-bot]

Created by: benfry

Yeah, NEWT doesn't like AWT either, so throwing it out there as a possibility for headaches. (NEWT was part of the reason that the AWT separation process began in the first place. And the non-AWT approach in JavaFX was an accelerant.)

I don't suppose there's a newer JOGL release? Anyone else having issues on the JOGL forums/issue tracker? Other things I would try:

• Does it work outside the PDE, just using core.jar and the rest as a Java application?
• Does the newer JDK work with the alpha 1 code?

[processing-bot]

Created by: sampottinger

Hey there!

No, unfortunately, we are on the latest and didn’t see anything in forums or bug tracker (though another look wouldn’t hurt). Those are great questions! I’ll try to look into them probably late this week.

Thanks,
Sam

On Aug 23, 2020, at 1:43 PM, Ben Fry [email protected] wrote:


Yeah, NEWT doesn't like AWT either, so throwing it out there as a possibility for headaches. (NEWT was part of the reason that the AWT separation process began in the first place. And the non-AWT approach in JavaFX was an accelerant.)

I don't suppose there's a newer JOGL release? Anyone else having issues on the JOGL forums/issue tracker? Other things I would try:

Does it work outside the PDE, just using core.jar and the rest as a Java application?
Does the newer JDK work with the alpha 1 code?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[processing-bot]

Created by: sampottinger

Hey @benfry! I ran the tests you requested.

Does it work outside the PDE, just using core.jar and the rest as a Java application?

Unfortunately, no. Please see attached.

Does the newer JDK work with the alpha 1 code?

Again, unfortunately, no. See https://github.com/processing/processing4/tree/alpha_1_jogl_test.

[processing-bot]

Created by: sampottinger

@benfry / @codeanticode, let me know if there's any more I can do!

[processing-bot]

Created by: benfry

Maybe it's LWJGL time. Heh, heh. Heh. Cough. Hrmph.

[processing-bot]

Created by: benfry

Ok, found a really ugly hack that gets around things for now. On macOS, setting a flag to toggle the resizability of the window, which seems to revalidate it or recreate it internally. I'm still guessing that we're doing something wrong on window init, but haven't been able to track that down.

For folks using surface.setResizable(true) in setup(), that'll temporarily need to move to draw(). (This is noted in changes.md.)

It's super gross, but at least this will work for the vast majority of others.

Not marking this as resolved, since a real solution needs to be found.

[processing-bot]

Created by: benfry

For what it's worth, when testing on an M1 laptop, was seeing some persistent flickering, so now I'm wondering if there's a buffer swapping/offscreen buffer issue happening here. Similar to what we run into with offscreen buffer issues with weird graphics drivers or limited VRAM. Not certain, but worth checking into…

[processing-bot]

Created by: benfry

Fixed with the latest RC of JOGL (v2.4.0-rc-20210111) in 4.0 alpha 3.