New tutorial on AWT/SWT/Swing/GLJPanel/GLCanvas

Sven Gothel wrote

Hence it 'breaks' the contract of providing a current _and_ usable HDC via wglGetCurrentDC().

Maybe this was never the contract?  JOGL 1 never uses any DC in GLDrawableFactory.createExternalGLContext(), which implies that it wasn't considered available. ExternalGLContext was purely a wrapper for the GLContext, without much extra info.

Also, I can't think how to make my example cross-platform. The hack I showed before:

int hDC = OS.GetDC( glcanvas.handle );
GLContext glcontext = GLDrawableFactory.getFactory( glprofile ).createExternalGLContext();
OS.ReleaseDC(glcanvas.handle, hDC);

is Windows-only, since SWT GLCanvas doesn't contain a handle on Mac or Linux. The handle is actually supposed to be a private member, but SWT had to make it public to share it inside SWT's own packages.

My hack is also 32-bit only, since on 64-bit Windows the handle is a "long" instead of an "int". This is transparent inside SWT, but if you try to use the handle outside SWT, you expose that platform dependence. SWT actually modifies their source code at compile time to differentiate the 32-bit and 64-bit cases and create two separate JARs

On Saturday, February 12, 2011 07:31:29 Wade Walker [via jogamp] wrote:
>
> Sven Gothel wrote:
> >
> > Hence it 'breaks' the contract of providing a current _and_ usable HDC via
> > wglGetCurrentDC().
> >
>
> Maybe this was never the contract?  JOGL 1 never uses any DC in
> GLDrawableFactory.createExternalGLContext(),
JOGL1 is hardly the reference here :)

But the semantics of MakeCurrent(context, drawable) for EGL, WGL, XGL, CGL ..
which imply a valid accessible drawable until release.
This is mentioned the the email I referenced ..

So Windows goes around this, render it somehow invalid, an SWT hack
to not have to release it later on - well :)

> which implies that it wasn't
> considered available. ExternalGLContext was purely a wrapper for the
> GLContext, without much extra info.

how to makecurrent/release w/o it ?

well, it is the platform's window handle, so its all cool.

>
> My hack is also 32-bit only, since on 64-bit Windows the handle is a "long"
> instead of an "int". This is transparent inside SWT, but if you try to use
> the handle outside SWT, you expose that platform dependence. SWT actually
> modifies their source code at compile time to differentiate the 32-bit and
> 64-bit cases and create two separate JARs
autch :)

and I was wondering what that means .. /* long */ :)

hmm, so even we would need to use reflection for this one
to allow our code to stay platform independent.

well, I try with WindowFromDC(hdc) 1st as an attempt to fix this in the external context.

the right fix, real SWT binding later.

thank you for doing this with me, very helpful.

Cheers, Sven

On Saturday, February 12, 2011 09:56:08 Sven Gothel wrote:
Ok, I read the API doc :)

MakeCurrent/Release is not job of the JOGL external context,
and it's implementation/action is a nop.

Hence no drawable must be available, and no further information
is indeed necessary.

Will follow the API doc .. :)

Thanks Wade

Sven Gothel wrote

Ok, I read the API doc :)

I wish I had thought of that  I totally forgot that we have the JSR-231 to work from.

I think JOGL 2 is extremely close to running on every platform I have available, with every possible windowing system -- I'm very excited to try out the next release

Hi Wade / all,

I went through Wade's tutorial for GLJPanel and Swing, and it worked like a charm (using B298, 32bit Windows xp).

I've since moved on to creating a JFrame, with JInternalFrames.  I've added JPanels to the JInternalFrames, as well as a GLJPanel to a JInternalFrame.

I use an FPSAnimator to update the GLJPanel in one of my JInternalFrames (the triangle just like in Wade's example).  This works fine.

From a main thread, I am calling repaint at a regular interval on a JPanel in another JInternalFrame.  This causes an image to update in that JPanel.  This worked fine, until I added the JInternalFrame that has the GLJPanel.  Now it "flickers."

Assuming that I need to be able to make the periodic repaint request, is there another way I should be doing this?  My understanding of the repaint request is that it gets executed eventually on the Swing Event thread.  The fact that the GLJPanel is being rendered by the FPSAnimator separately shouldn't seem to have an impact.

Any suggestions would be greatly appreciated.

Does it flicker white? If so, its background paint event may be getting triggered somehow, or part of its area may be getting invalidated by events coming from the FPSAnimator. You might make sure that none of the panels overlap, and that no events are getting sent to a parent which might cause children to be invalidated (assuming your panels are siblings).

Perhaps one of the other guys with more Swing experience has a clever suggestion -- I've mostly used SWT, so I'm not as familiar with Swing

I have the same problem, it works until I use JDesktopPane and/or JInternalFrame. I haven't found any solution.

Thank you both for the feedback.  I'll investigate further and post an update here later today.

Wade, forgot to answer your question - yes, the background flickers white.

I also confirmed that if I pause the Animator, the flickering on my JPanel that is displaying an updating image stops.  It looks like the Animator is firing an event that is invalidating my "image" JPanel.  A bit odd, since the GLJPanel is in one internal frame and my "image" JPanel is in a completely separate JInternalFrame (both internal frames added to a JDesktop, which is added to a JFrame).

euclidix wrote

It looks like the Animator is firing an event that is invalidating my "image" JPanel.

Yeah, that's what I was guessing  It should be straightforward to track down -- just breakpoint the invalidation code and see where it's getting called from. I've seen this sort of thing before, and usually it's a mutual parent being invalidated, which invalidates the other children.

I have a workaround.

Manually calling display() on the GLJPanel (vice using an Animator) resolves the issue.  The JavaDoc confirms that a manual call on display() is legal.  

Wade, I'll see if I can dig into the Animator class a bit, however, I'm not currently set up with the source (my OpenGL experience extends about 3 days now, and I only just setup JOGL over the weekend).

It looks like the class AWTAnimatorImpl (instantiated inside FPSAnimator) may be what you're looking for. It seems to contain logic that can traverse up the drawable hierarchy looking for things to call display on, and it may be behaving unexpectedly.

If you need any help building JOGL to trace into the code, just check the wiki pages at http://jogamp.org/wiki/index.php/Building_JOGL_on_the_command_line and http://jogamp.org/wiki/index.php/Building_JOGL_in_Eclipse.

Hi Wade,

Did you have any time to look into the SWT's Context GL3 support?
Sooner or later I might have to look into this deeper, as it's blocking me from switching to the current builds of JOGL... It would be great If you could share any of your findings in that matter. :)

Matt.

I haven't looked into it any further yet. Right now I'm trying to support Sven with testing to help get JOGL 2's SWT support working correctly on 32-bit Windows XP systems. Then I was planning to finish and submit my SWT patch that adds multisampling on Windows, just to dip my toe into the water and see if the SWT guys will take patches and incorporate them.