Switched to JDK 1.7, GLCanvas buggy on mac

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Switched to JDK 1.7, GLCanvas buggy on mac

Fauldsh
I haven't started a bug report because I'm not entirely sure whether this is a bug in jogl or elsewhere (or how to submit a bug report).

I recently started using some Java 1.7 features in a project that I've been working on in both Windows and OSX. This worked fine in Windows but now GLCanvas is behaving weirdly in OSX. The best way to describe it is that the contents if GLCanvas is resizing randomly. I provided a video of it happening in a stripped down test case:

VIDEO: http://www.youtube.com/watch?v=4cXzDPvsJYA
CODE: https://gist.github.com/3089608

The console output reveals that the canvas is actually maintaining the appropriate size despite the appearance to the contrary.

The error "XXXX-XX-XX XX:XX:XX.XXX java[XXXX:XXX] invalid drawable" is received each time it renders inaccurately.

In my actual application this is happening not just when resizing (I haven't nailed down exactly why it's happening at the particular point it is but it's just after adding more objects to render).
Reply | Threaded
Open this post in threaded view
|

Re: Switched to JDK 1.7, GLCanvas buggy on mac

Xerxes Rånby
2012-07-11 12:56, Fauldsh [via jogamp] skrev:
I haven't started a bug report because I'm not entirely sure whether this is a bug in jogl or elsewhere (or how to submit a bug report).

I recently started using some Java 1.7 features in a project that I've been working on in both Windows and OSX. This worked fine in Windows but now GLCanvas is behaving weirdly in OSX. The best way to describe it is that the contents if GLCanvas is resizing randomly. I provided a video of it happening in a stripped down test case:

VIDEO: http://www.youtube.com/watch?v=4cXzDPvsJYA
CODE: https://gist.github.com/3089608

The console output reveals that the canvas is actually maintaining the appropriate size despite the appearance to the contrary.

The error "XXXX-XX-XX XX:XX:XX.XXX java[XXXX:XXX] invalid drawable" is received each time it renders inaccurately.

In my actual application this is happening not just when resizing (I haven't nailed down exactly why it's happening at the particular point it is but it's just after adding more objects to render).


Remember that Swing and AWT is a single threaded framework, you must guarantee that Swing and AWT calls runs on the Event Dispatch Thread or strange things will/may happen.
If you want the full background then read the JavaSE swing concurrency tutorial:
http://docs.oracle.com/javase/tutorial/uiswing/concurrency/index.html

For example try use the SwingUtilities.invokeLater to make sure that swing and awt updates happens on the Event Dispatch Thread.

Change

canvas.setPreferredSize(new Dimension(drawable.getWidth(), drawable.getHeight()));

to

SwingUtilities.invokeLater(new Runnable() {
  public void run() {
    canvas.setPreferredSize(new Dimension(drawable.getWidth(), drawable.getHeight()));
  }
});

and change

  public static void main(String ... args) {
    new Main();
  }

to

  public static void main(String ... args) {
    SwingUtilities.invokeLater(new Runnable() {
      public void run() {
        new Main();
      }
    });
  }

I hope this helps.

If you reply to this email, your message will be added to the discussion below:
http://forum.jogamp.org/Switched-to-JDK-1-7-GLCanvas-buggy-on-mac-tp4025496.html
To start a new topic under jogamp, email [hidden email]
To unsubscribe from jogamp, click here.
NAML

Reply | Threaded
Open this post in threaded view
|

Re: Switched to JDK 1.7, GLCanvas buggy on mac

Fauldsh
Ok, I made some changes and stripped even more out (https://gist.github.com/3090470). Weirdly if I compile for Java 1.6 and run using the Java SE 6 (MacOS X Default) it works fine. Whilst resizing is still quite jerky in 1.6 there is no random resizing as in 1.7. Not sure what to make of this.
Reply | Threaded
Open this post in threaded view
|

Re: Switched to JDK 1.7, GLCanvas buggy on mac

Pixelapp
I'm pretty sure Xerxes know a lot about this than I do but...

Would you consider switching from GLCanvas to GLWindow. There is a tutorial about this at Jogamp.org.

Also, I say this because not only you may encounter the problem you describe but I think you will also be unable to set Full Screen on Mac as well.

More over, GLWindow works for android which is the opposite for GLCanvas.
Reply | Threaded
Open this post in threaded view
|

Re: Switched to JDK 1.7, GLCanvas buggy on mac

gouessej
Administrator
You're right, good advice. Use GLCanvas only if you need some sort of interoperability with AWT. Exclusive full screen mode is broken under GNU Linux with KDE 4 in AWT too. Whatever the canvas you use, take care of the threading.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Switched to JDK 1.7, GLCanvas buggy on mac

Fauldsh
Thanks for the tip guys, still curious to know what's causing the underlying bug (and why i still get one invalid drawable error) but using newt now and it works.
Reply | Threaded
Open this post in threaded view
|

Re: Switched to JDK 1.7, GLCanvas buggy on mac

Sven Gothel
Administrator
In reply to this post by Fauldsh
On 07/11/2012 04:01 PM, Fauldsh [via jogamp] wrote:
> Ok, I made some changes and stripped even more out
> (https://gist.github.com/3090470). Weirdly if I compile for Java 1.6 and run
> using the Java SE 6 (MacOS X Default) it works fine. Whilst resizing is still
> quite jerky in 1.6 there is no random resizing as in 1.7. Not sure what to
> make of this.

This 'jerky' behavior is well known, see bug
  <https://jogamp.org/bugzilla/show_bug.cgi?id=569>
  <https://jogamp.org/bugzilla/show_bug.cgi?id=599>

Today or tomorrow I may finish my 1st draft of the FBO offscreen
drawable, allowing resize w/o recreation of drawable/context.

On OpenJDK 1.7 the AWT related GLDrawable is always offscreen
as with Applets on OSX >= 10.5.8 and Java6 - since it's the only
JAWT hook they provide (CALayer).

~Sven


signature.asc (910 bytes) Download Attachment