jogamp › jogl

GLCanvas in CardLayout

Classic

List

Threaded

26 messages Options

Gene

Re: GLCanvas in CardLayout

Please send it. It will take a little while to make a development environment on the machine where the bug is, but I'll do it as quickly as possible. I'm registered and logged in now.

Again I appreciate the help.

Gene

Gene

Re: GLCanvas in CardLayout

In reply to this post by Gene

I also doubt these are the same thing, as I'm not getting an exception at all. The window is just blank.

I'll probably be able to spend some time looking at the new WGL calls tomorrow.

Cheers.

PS. A coincidence. I'm in France. I auch spreche ein bisschen (aber nur ein bisschen) Deutsch.

Wade Walker

Re: GLCanvas in CardLayout

Administrator

In reply to this post by Gene

I've sent you the tests via email. You don't need to make a dev environment on the buggy machine -- these tests are fully self-contained, with the JOGL JARs included in them. To attach the log files to a forum post, use "More > Upload a file".

Or you could also create a Bugzilla report for this bug to help us track its progress without cluttering the forums

Gene

Re: GLCanvas in CardLayout

This post was updated on .

I created Bugzilla report #532.

Just ran the tests that Wade furnished. Logs are attached to the Bugzilla report.

The JOGL 2 log is actually a link to our project site because the report was too long for Bugzilla.

This bug report has an additional note I just discovered: In JOGL 2 the same machine allocates a low-res depth buffer (looks like only 16 bits; I have some work to figure out if this is correct), where JOGL 1 allocated at a higher res. I'm noting this in case it's possible the different choice JOGL 2 is making is invoking a driver path with a bug in it. I will try fiddling with Capabilities paremeters tonight to see if I can coax a different behavior in this manner.

Thanks for all your help.

Gene

Re: GLCanvas in CardLayout

In reply to this post by Gene

Greetings,

I may have a fix, but am more puzzled than ever.

I tried removing the animator in the pared down example, and good news: the GLCanvas card started flipping correctly, responding to paint(), no longer dead.

I tried this because Wade had a hunch that the problem may be a missing MakeCurrent somewhere that the NVIDIA card tolerates and the Intel card does not. The animator has a timer thread, so taking it out of the picture seemed a way to reduce chances for such a bug to manifest.

Another clue in Wade's favor: If I start() the animator just once when it's created, use pause() / resume() in place of stop() / start() in the button actions, and finally call stop() just once when the canvas is disposed, all works correctly. The only difference between pause/resume and start/stop is that the latter create/destroy a timer, including its thread. Pause/resume use the same timer.

Incidentally, the reason for pause/resume in addition to start/stop is not explained in the FPSAnimator API docs. So maybe I've just discovered the way the timer is supposed to be used?

I'd really appreciate comments from the experts on this.

I will copy this note on Bugzilla for the record.

Thanks.

Sven Gothel

Re: GLCanvas in CardLayout

Administrator

On Tuesday, December 13, 2011 11:42:55 PM Gene [via jogamp] wrote:

>
> Greetings,
>
> I may have a fix, but am more puzzled than ever.
>
> I tried removing the animator, and good news: the GLCanvas card started
> flipping correctly, responding to paint(), no longer dead.
>
> I tried this because Wade had a hunch that the problem may be a missing
> MakeCurrent somewhere that the NVIDIA card tolerates and the Intel card does
> not. Animators have timer threads, so taking a thread out of the picture
> seemed reasonable.
>
> Another clue in Wade's favor: If I start() the animator just once when it's
> created and then use pause() / resume() in place of stop() / start() in the
> button actions, and finally call stop() just once when the canvas is
> disposed, all seems to work correctly. The only difference between
> pause/resume and start/stop is that the latter create and destroy a new
> timer, including its thread. Pause/resume use the same timer.
>
> Incidentally, the reason for pause/resume in addition to start/stop is not
> explained in the API docs. So maybe I've just discovered the way the timer
> is supposed to be used?
>
> I'd really appreciate comments from the experts on this.
>
> I will copy this note on Bugzilla for the record.
>
> Thanks.

Great work, discussion cont. on:

https://jogamp.org/bugzilla/show_bug.cgi?id=532

~Sven