Mac Canvas3D location bug

Using the 10/19/13 release of jogl: on OSX, using setBounds on GLCanvas only seems to set the origin initially.  Subsequent setBounds calls only set the height/width and leave the lower left location of the window the same.

I modified my test to animate moving the canvas across the screen while changing its size.  The window should move to the right, getting shorter and wider as it goes.  It works for the latest jre in windows (7u45) but fails under the 1.7.0_45-b18 in Safari on OSX 10.8.5.  It does work correctly if you run it on the command line in OSX though.

package test;

import java.applet.Applet;
import java.awt.Color;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import javax.media.opengl.GL;
import javax.media.opengl.GLAutoDrawable;
import javax.media.opengl.GLCapabilities;
import javax.media.opengl.GLCapabilitiesImmutable;
import javax.media.opengl.GLEventListener;
import javax.media.opengl.GLProfile;
import javax.media.opengl.awt.GLCanvas;
import javax.swing.JFrame;
import javax.swing.JPanel;

public class JoglCanvasTest extends Applet implements GLEventListener {

  public JoglCanvasTest() {
  }

  public static JFrame frame;
  public static JPanel appletHolder;
  public static boolean isApplet = true;
  public static GLCanvas canvas;
  public static int canvasXLocation = 50;

  static public void main(String args[]) {
    Applet myApplet = null;
    isApplet = false;

    myApplet = new JoglCanvasTest();
    appletStarter(myApplet, "JoglCanvasTest", 800, 600);
  }

  static public void appletStarter(final Applet des, String frameName, int width, int height) {
    appletHolder = new JPanel();
    if (frame != null) {
      frame.dispose();
      frame = null;
    }
    frame = new JFrame(frameName);
    frame.setVisible(false);
    frame.getContentPane().add(appletHolder);

    appletHolder.setLayout(null);
    des.setBounds(0, 0, width, height);
    appletHolder.add(des);

    frame.setVisible(true);
    int frameBorderSize = appletHolder.getLocationOnScreen().x - frame.getLocationOnScreen().x;
    int titleBarHeight = appletHolder.getLocationOnScreen().y - frame.getLocationOnScreen().y;
    int frameWidth = width + 2 * frameBorderSize;
    int frameHeight = height + titleBarHeight + frameBorderSize;
    frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    frame.setSize(frameWidth, frameHeight);
    frame.setVisible(true);
    des.init();
    frame.addWindowListener(new WindowAdapter() {
      public void windowClosing(WindowEvent e) {
        System.exit(0);
      }
    });
  }

  public void init() {
    initOpenGLAWT();
    
    Runnable r = new Runnable() {
      public void run() {
        try {
          int loop = 0;
          while (loop < 3) {
            Thread.sleep(1000);
            canvasXLocation += 50;
            if (canvasXLocation > 300) {
              canvasXLocation = 0;
              loop++;
            }
            canvas.setBounds(canvasXLocation, 50, 200 + canvasXLocation, 450 - canvasXLocation);
          }
        } catch (Exception e) {
        }
      }
    };

    new Thread(r).start();

  }

  public void initOpenGLAWT() {
    setBackground(Color.gray);
    setLayout(null);

    GLProfile glp = GLProfile.getDefault();
    GLCapabilities caps = new GLCapabilities(glp);
    canvas = new GLCanvas((GLCapabilitiesImmutable) caps);
    canvas.setBounds(50, 50, 200, 450);
    canvas.addGLEventListener(this);
    add(canvas);
  }

  public void init(GLAutoDrawable gLAutoDrawable) {
    GL gl = gLAutoDrawable.getGL();
    gl.glClearColor(1.0f, 0.0f, 0.0f, 1.0f);
    gl.glClear(GL.GL_COLOR_BUFFER_BIT);
    gLAutoDrawable.swapBuffers();
  }

  public void dispose(GLAutoDrawable glad) {
  }

  public void display(GLAutoDrawable glad) {
  }

  public void reshape(GLAutoDrawable glad, int i, int i1, int i2, int i3) {
  }

}

On 10/23/2013 11:15 PM, jimthev [via jogamp] wrote:
> Using the 10/19/13 release of jogl: on OSX, using setBounds on GLCanvas only
> seems to set the origin initially.  Subsequent setBounds calls only set the
> height/width and leave the lower left location of the window the same.
>
> I modified my test to animate moving the canvas across the screen while
> changing its size.  The window should move to the right, getting shorter and
> wider as it goes.  It works for the latest jre in windows (7u45) but fails
> under the 1.7.0_45-b18 in Safari on OSX 10.8.5.  It does work correctly if you
> run it on the command line in OSX though.

I saw the same behavior w/ the 'sliding' demo and applets on OSX,
while working as standalone in a JFrame (on OSX).
IMHO a bug in AWT/OSX.

Please create a new bug report, with _low_ priority,
and add your unit test.
Pls copy one of the Bug816 Applet tests.

Related:
  <https://jogamp.org/bugzilla/show_bug.cgi?id=816>

Quite possible that we don't fix this one.
However, you and others are very very welcome to help.

Thank you.

Cheers, Sven

Hi,
I don't know if I should continue to post here or create an other subject, but I've been trying under Mac OS X the first Beta of Java 7u60 where the Canvas3D location bug seems to be back.
Before contacting Oracle team, are you aware of some additional changes that should be made in JOGL or Java 3D for this future Java release, or do you think it's a regression in Java?
You can test the issue with this simple program that displays a 3D canvas in the top right corner of a frame:

import java.awt.GraphicsEnvironment;
import javax.media.j3d.*;
import javax.swing.*;
import com.sun.j3d.utils.universe.SimpleUniverse;

public class Canvas3DPositionTest {
  public static void main(String [] args) {
    // Create a canvas 3D
    GraphicsConfigTemplate3D gc = new GraphicsConfigTemplate3D();
    Canvas3D canvas = new Canvas3D(GraphicsEnvironment.getLocalGraphicsEnvironment().
        getDefaultScreenDevice().getBestConfiguration(gc));
    new SimpleUniverse(canvas);

    // Build a GUI where the canvas 3D is located at top right of the frame 
    // and can be resized with split panes dividers
    JFrame frame = new JFrame("Canvas3DPositionTest");
    JSplitPane verticalSplitPane = new JSplitPane(JSplitPane.VERTICAL_SPLIT, 
        true, canvas, new JScrollPane());    
    verticalSplitPane.setResizeWeight(0.5);
    JSplitPane horizontalSplitPane = new JSplitPane(JSplitPane.HORIZONTAL_SPLIT, 
        true, new JScrollPane(), verticalSplitPane);
    horizontalSplitPane.setResizeWeight(0.5);
    JRootPane intermediateRootPane = new JRootPane();
    intermediateRootPane.setContentPane(horizontalSplitPane);
    frame.add(intermediateRootPane);
    frame.setSize(400, 400);
    frame.setVisible(true);
  }
}

Move the horizontal splitter and you'll see that the canvas 3D location is incorrect one time out of two.

Hi all,

I did a test on mac today and I found that with new JOGL 2.1.3, the canvas3D shift is back.

I made the test with java 1.7u45, java 1.6-pre9, JOGL 2.1.2: OK
With java 1.7u45, java 1.6-pre9, JOGL 2.1.3, canvas3D is shifted.

So it should come from new jogl 2.1.3. at least, there is a change.


Laurent.

On 12/18/2013 03:08 PM, jimmypag [via jogamp] wrote:
> Hi all,
>
> I did a test on mac today and I found that with new JOGL 2.1.3, the canvas3D
> shift is back.
>
> I made the test with java 1.7u45, java 1.6-pre9, JOGL 2.1.2: OK
> With java 1.7u45, java 1.6-pre9, JOGL 2.1.3, canvas3D is shifted.
>
> So it should come from new jogl 2.1.3. at least, there is a change.

Thank you for finding the regression!

It's fixed:
  <https://jogamp.org/bugzilla/show_bug.cgi?id=928>

and will be part of 2.1.4 ofc:

<https://jogamp.org/wiki/index.php/SW_Tracking_Report_Objectives_for_the_release_2.1.4>

~Sven

Hi all and happy new year 2014,

I just tested the current beta of JOGL (gluegen-2.1-b760 and jogl-2.1-b1198 built on the January 9th) with the second Beta of Java 7u60 and got the same error as previously. Do you think it's a regression in Java or some additional adjustments required in JOGL?

On 01/10/2014 06:26 PM, Manu [via jogamp] wrote:
> Hi all and happy new year 2014,
>
> I just tested the current beta of JOGL (gluegen-2.1-b760 and jogl-2.1-b1198
> built on the January 9th) with the second Beta of Java 7u60 and got the same
> error as previously
> <http://forum.jogamp.org/Mac-Canvas3D-location-bug-tp4030052p4030838.html>. Do
> you think it's a regression in Java or some additional adjustments required in
> JOGL?

A regression :(

The JAWTWindow visibility tracking got put of hand,
i.e. too complicated, too many sideeffects.

See <https://jogamp.org/bugzilla/show_bug.cgi?id=937#c5>

I had to replace it with a much more simplified logic,
please test:

  maven: 2.1.4-rc-20140113
  <http://jogamp.org/deployment/archive/master/gluegen_759-joal_509-jogl_1195-jocl_901/>
  <http://jogamp.org/deployment/archive/master/gluegen_761-joal_511-jogl_1200-jocl_903-signed/>

Please report results.

Sorry & Thank you!

~Sven

> Emmanuel Puybaret
>

Sven Gothel wrote

A regression :(

Shall we submit it to Oracle / OpenJDK? If yes, I would be ok to do it, except that you're in a much better technical position to submit a bug with all the information that will help Oracle to fix it quickly.

Sven Gothel wrote

I had to replace it with a much more simplified logic,
please test:

  maven: 2.1.4-rc-20140113
  <http://jogamp.org/deployment/archive/master/gluegen_759-joal_509-jogl_1195-jocl_901/>
  <http://jogamp.org/deployment/archive/master/gluegen_761-joal_511-jogl_1200-jocl_903-signed/>

Please report results.

 
Sorry, it doesn't work better with the last test I posted here.
When you move the vertical split pane divider to change canvas abscissa, the canvas is placed in the lower left corner one time out of two.
And in Sweet Home 3D case, once I close a window that contains a 3D canvas, the program gets blocked some way (with any Java version 1.6.0_65, 1.7.0_40 or 1.7.0_60 beta). This must be bound to canvas disposal, because if you add the following statements to  Canvas3DPositionTest, the test gets blocked too:

    // Wait a little to ensure that the frame is visible
    Thread.sleep(1000);
    // Dispose the frame and display it again
    frame.dispose();
    frame.setVisible(true);

On 01/14/2014 11:25 AM, Manu [via jogamp] wrote:
>     Sven Gothel wrote
>     A regression :(
>
> Shall we submit it to Oracle / OpenJDK? If yes, I would be ok to do it, except
> that you're in a much better technical position to submit a bug with all the
> information that will help Oracle to fix it quickly.

Great, do it then.
You can simply post the test case and state that the CALayer's position
seems to be handled differently w/ respective java versions.

I will test w/ that version later on ..
That is expected, since you don't run it on the AWT EDT
after 1st visible command.

Also pls use the test cases I added based on your work
so we stay on the same page, i.e.:

  <http://jogamp.org/deployment/archive/master/gluegen_761-joal_511-jogl_1200-jocl_903-signed/jogl-applet-bug816_layerpos03a.html>
     com.jogamp.opengl.test.junit.jogl.awt.TestBug816OSXCALayerPos03aB729AWT

  <http://jogamp.org/deployment/archive/master/gluegen_761-joal_511-jogl_1200-jocl_903-signed/jogl-applet-bug816_layerpos03b.html>
     com.jogamp.opengl.test.junit.jogl.awt.TestBug816OSXCALayerPos03bB849AWT

~Sven

On 01/14/2014 04:07 PM, Sven Gothel wrote:
>
> Also pls use the test cases I added based on your work
> so we stay on the same page, i.e.:
>
>   <http://jogamp.org/deployment/archive/master/gluegen_761-joal_511-jogl_1200-jocl_903-signed/jogl-applet-bug816_layerpos03a.html>
>      com.jogamp.opengl.test.junit.jogl.awt.TestBug816OSXCALayerPos03aB729AWT
>
>   <http://jogamp.org/deployment/archive/master/gluegen_761-joal_511-jogl_1200-jocl_903-signed/jogl-applet-bug816_layerpos03b.html>
>      com.jogamp.opengl.test.junit.jogl.awt.TestBug816OSXCALayerPos03bB849AWT

'Standalone' test is:
  com.jogamp.opengl.test.junit.jogl.awt.TestBug816OSXCALayerPos02AWT
not TestBug816OSXCALayerPos03aB729AWT, TestBug816OSXCALayerPos03bB849AWT

reproduced w/ 7u60-ea-b02 .. oh well,
looks like they do this now for every release :)

~Sven

On 01/14/2014 05:19 PM, Sven Gothel wrote: Ok - it's our fault :-/

We didn't parse the 'update' version well,
i.e. failed due to the postfix '-ea'.

A fix is underway ..

~Sven

On 01/14/2014 07:06 PM, Sven Gothel wrote:
> Ok - it's our fault :-/
>
> We didn't parse the 'update' version well,
> i.e. failed due to the postfix '-ea'.
>
> A fix is underway ..
>
https://jogamp.org/bugzilla/show_bug.cgi?id=944

> ~Sven
>

Hi all,
I'm having trouble with resizing my Canvas3D in Mac OS X. When the gui is initialized it's drawn perfectly but when it resize it the canvas size doesn't change. The Canvas3D is inside a JSliptPane and its size doesn't change when moving the split divider or when resizing the JFrame. Instead it always sticks to lower left corner. This problem only occurs in Mac OS X.

I'm using Java 1.7 update 51, in Mac OS X 10.8.5
I'm using Java3D [dev] 1.6.0-pre9-daily-experimental daily

Is this problem the same as the one being discussed here or should I open a new forum subject?
If it's this one, is there a fix available.? Reading through this forum it's unclear to me whether or not a fix is available yet.

On 01/25/2014 06:18 PM, runiter [via jogamp] wrote: Please look here:
  <https://jogamp.org/bugzilla/show_bug.cgi?id=946#c2>

Try with a new 'test' build .. thank you.

I guess you simply can replace GlueGen+JOGL jar files in Java3D ..

~Sven

Sven, where can I find the new 'test' build jar files?
a direct link is appreciated.

On 01/25/2014 10:34 PM, runiter [via jogamp] wrote:
> Sven, where can I find the new 'test' build jar files?
> a direct link is appreciated.

Please follow the URL I have added in my last message.

(I do those things for a reason :)

~Sven

oops my bad...i followed the link but didn't realize the download link was there.

Anyways I got the latest version and it works perfectly with resizing now. Thank you.

I just tried gluegen-2.1-b770 and jogl-2.1-b1213 with Java 3D 1.6-pre9 under Java 1.6.0_65, 7u40 and 7u60.
The location bug is gone. Great!
But once I close a window that contains a 3D canvas, the program still gets blocked some way, and as the following test shows, this is not bound to AWT EDT handling (but maybe it's the same bug as this one?).

package com.eteks.sweethome3d.test;

import java.awt.EventQueue;
import java.awt.GraphicsEnvironment;
import javax.media.j3d.*;
import javax.swing.*;
import com.sun.j3d.utils.universe.SimpleUniverse;

public class Canvas3DDisposeTest {
  public static void main(String [] args) throws InterruptedException {
    EventQueue.invokeLater(new Runnable() {
      public void run() {
        // Create a canvas 3D displayed in a frame
        GraphicsConfigTemplate3D gc = new GraphicsConfigTemplate3D();
        Canvas3D canvas = new Canvas3D(GraphicsEnvironment.getLocalGraphicsEnvironment().
            getDefaultScreenDevice().getBestConfiguration(gc));
        new SimpleUniverse(canvas);
        
        JFrame frame = new JFrame("Canvas3DDisposeTest");
        frame.add(canvas);    
        frame.setSize(400, 400);
        frame.setVisible(true);

        JOptionPane.showMessageDialog(frame, "Frame will be disposed and shown again");
        frame.dispose();
        frame.setVisible(true);       
        JOptionPane.showMessageDialog(frame, "Frame was shown again");
      }
    });
  }
}

Emmanuel, thank you for the short test case as usual. I'm really worried as this bug is reproducible with something so basic.

On 01/27/2014 01:11 PM, Manu [via jogamp] wrote:
> I just tried gluegen-2.1-b770 and jogl-2.1-b1213 with Java 3D 1.6-pre9 under
> Java 1.6.0_65, 7u40 and 7u60.
> The location bug is gone. Great!
> But once I close a window that contains a 3D canvas, the program still gets
> blocked some way, and as the following test shows, this is not bound to AWT
> EDT handling

Emmanuel, thank you for the heads up.

As I have asked you earlier, please
use one of our existing JOGL only unit tests
and reproduce the issue (edit it) - and post it
inclusive the stack trace. Best in a bug report.
(Iff this is assumed to be a JOGL bug)

It's quite a burden to revalidate _new_ tests,
reading new code - if one could use the existing tests and change them.
Especially if they involve another module, here Java3D.

If you could do the above - it would safe alot of my time
and help all of us validating w/ same test cases.
Further more - the new unit test would be included
in our repository, and hence will get tested w/ jenkins!

BTW .. the above is true for all bugreports, ofc.

Thank you!

~Sven