[quote]You won’t get an init() until you start calling display() on the GLDrawable.
[/quote]
Umm… What’s the difference between init method and the first call to display method then? I think someone should rethink some parts of the event architecture :).
Edit: Also, I’ve seen far too many cases where someone adds the component x into y in the wrong order. These cases should be either documented or corrected to work in a more intuitive way.
There’s a huge difference. You need to go read the OpenGL docs. Also understanding what GLUT does would be helpful too, because JOGL is modelled after the GLUT callback architecture.
[quote]There’s a huge difference. You need to go read the OpenGL docs. Also understanding what GLUT does would be helpful too, because JOGL is modelled after the GLUT callback architecture.
[/quote]
Really? I’m silly in that way… I understand OpenGL but I still have problems understanding JOGL sometimes. Also, where is it documented that JOGL works on top of GLUT? GLUT is not a requirement for a casual OpenGL program.
A Java library should work nevertheless.
It’s not implemented on top of GLUT, it just uses the same design concepts. The one difference is that GLUT does it’s own event/callback loop, where JOGL needs to be externally clocked somehow - hence the presence of the display() method on GLDrawable.
Yeah, sorry I misread the message. I can understand the requirement for the display method and the motivation behind it, but why is the init method defined to be “triggered” after the first display? Is this behavior due to a lazy initialization of the used OGL context? If so, could it be modified to occur already in the show (or setVisible) method of the component (glDrawable owner)?
Right now I am initializing my textures, creating my display lists, and doing some other basic ‘initialization’ in my init method, basically my display method isn’t going to work before initialization is done. Is it just me or does it seem wrong that I have to try and display what I’m initializing before I initialize it? do I really need to add something like
if(!intialized)
{
//do initialization.
initialized = true;
}
else
{
//display code.
}
instead of using the init method? If this is true, what exactly is the init method for? I’m sure there is a reason for this, but I’ve never heard mention of it in any of the tutorials I’ve read…
I just checked out the jogle ported nehe tutorials and sure enough they are doing the same thing:
create canvas
add listener
add canvas to frame
set frame to visible
plus they are loading their textures and building their display lists from init.
It should be noted that I did not learn jogl from these tutorials so the mistake must be pretty widespread. Perhaps some effort should be made to let people know about the correct way to setup jogl if it is such a problem.
The problem with JOGL is that it “mostly works” where “mostly” is defined for nVidia video cards. ATI cards are very problematic. Some work, some don’t. For example, JOGL running on my old laptop with a Mobility M3 runs the NeHe stuff fine. However, on my Radeon 9700 here in the office, it fails to start. Same thing with a couple of the 3DLabs cards we have here too. Some work, some don’t. It’s not entirely predictable either. The order above is the only one that we can get to reliably work on all video hardware.
Hi,
A simple question : Is this problem of same code working or not on different video cards a driver problem or a JOGL problem… (It is known that ATI are not the leader in openGl but…)
Well, in both cases, i raises a crucial issue, for me, that will prevent JOGL from spreading.
Since the display loop handling and all the listeners are implemented in Java, it’s a pure JOGL problem. Basically some interesting interactions are happening between the internals of the AWT code and OpenGL that are causing these problems. You could somewhat blame it on the drivers (there’s a host of other ATI-specific problems that JOGL has to deal with), but really it feels more of a JOGL implementation problem than drivers.
It is hard to say whether it is us or the drivers. I of course like to blame the drivers since I wrote some of the code. Some drivers just do not like our use of multiple threads. The most common error people see is wglChoosePixelFormatARB error: 0. That isn’t a valid error according to the spec. That error means the function failed but there is no error. Obviously something is very wrong with that on the driver end. I am as frustrated as you guys are so hopefully we can resolve this soon.
I agree. Multiple threads and JOGL just don’t mix. Anything beyond a trivial application we basically have to force the rendering loop into a single threaded environment and carefully feed data to it. That’s frustrating. However, we’ve been doing so much JOGL development over the last 10 months or so that we’re starting to feel pretty comfortable now with it and know what to avoid. That, and having a stable scene graph over the top of it certainly helps a lot at the application level - solve the problem once and it’s solved for all applications.