Can JOGL be used without requiring GLAutoDrawable instances?

gouessej wrote

JogAmp's Ardor3D Continuation contains almost 90 commits ahead of the legacy Ardor3D, I don't advise you to look at com.ardor3d.framework.jogl.JoglCanvas as I hesitated to deprecate it.

Which part would you advice me to look at and treat as a 'role model' section?

gouessej wrote

Using a plain animator (Animator) would allow you to keep concentrated on the rest. An animator can use some code specific to AWT depending on the drawable you use, look at AWTAnimatorImpl. Therefore, I advise you to use a plain animator even for a very dumb example.

Ok. Will look into this, and the above section, more closely.

Thanks in advance,
-x

Look at ExampleBase, JoglAwtCanvas, JoglSwingCanvas, ... Keep in mind that I had to avoid using any animator in this engine because of an early design decision (not mine). Therefore, a few complicated things are totally useless when you simply use an animator, especially those related to AWT.

gouessej wrote

Look at ExampleBase, JoglAwtCanvas, JoglSwingCanvas, ... Keep in mind that I had to avoid using any animator in this engine because of an early design decision (not mine). Therefore, a few complicated things are totally useless when you simply use an animator, especially those related to AWT.

Hi gouessej, et. al.,

I've been working on this on-and-off (had to take care of a few other things). I've gone through the files and a few other classes they collaborate with, etc. Unfortunately, I can't say that I'm getting any closer to what I'm trying to achieve --as described in my original post.

The Ardor code you referred me to shows something I think I was already familiar with or had a good idea of how to do, as mentioned previously (i.e. hiding the GLEventListener implementation in the renderer, etc.) I'm not sure I'm getting closer to better understanding what you're actually trying to suggest when it comes to the issue I had described.

I can post a full test/example of a working test I have, if that would help.

Please le me know if I should clarify in my original post to make sure I'm not causing some misunderstanding.

Thanks in advance,
-x

What do you fail to hide?

You can hide GLEventListener, you can use a static method to get the GL instance, you can use a static method to get the current OpenGL context, you can create your own abstraction to wrap GLAutoDrawable, you can use an animator without exposing it, you can put some OpenGL stuff into the queue with GLAutoDrawable.invoke(). What is still missing?

On 08/21/2015 11:24 AM, xghost [via jogamp] wrote: Just to make this long story maybe shorter:

It is 'just' about *work*.

Using the assisted API, i.e. GLAutoDrawable/GLEventListener
allows you to rely on our OpenGL + resources lifecycle support
and certain 'quirks' required to allow seamless operation on all
platforms, e.g. Android and OSX/AWT special cases.

The assisted model also supports certain features like:
  - Suspend an GLContext (make offscreen, destroy drawable -> re-animate).
  - Swap On- offscreen drawable
  - ..

If you control GLDrawable/GLContext yourself,
you operate on a much lower level.
This gives you more freedom, but also implies a much
higher responsibility, since you can crash things more easily.
Everything is available for this low level hacking
and you can of course copy/paste our code pieces from
GLAutoDrawable, GLCanvas etc. However, maintenance might become
your burden here.
This approach may also end up in just reinventing the wheel :)

In case you dislike the assisted path b/c of a missing
but essential feature, we can discuss it and add it together.

That said go for it .. whatever you choose!

Hope that helps a bit ..

~Sven

By the way, we don't have the same sense of humor. The next time I see a post insisting on mentioning repeatedly a competitor, I might ask others whether I should edit or delete it (we're in democracy, I don't make this kind of decision alone except for the obvious spams). This forum is a cool place to talk about JogAmp, the aim is to avoid being bothered with useless flame wars and debates unlike in numerous other forums and I want to do my best to keep it cool and friendly for JogAmp users.

gouessej wrote

By the way, we don't have the same sense of humor.

Hi gouessej,

I'm sure we don't. How did this come into the conversation and why is it relevant?...

I'm not sure what problem you seem to have here. Just guessing here, but if you're referring to this comment "yes, I dare disturb you by mentioning a competitor :D", the only reason I made it was because one of the devs/admins in this site had made a similar comment in a separate thread that I read before posting this one. (Not sure which thread it was and I'm not going to go look for it again.)

No one seemed offended there, and I don't see why you should somehow feel offended here...

gouessej wrote

The next time I see a post insisting on mentioning repeatedly a competitor, I might ask others whether I should edit or delete it (we're in democracy, I don't make this kind of decision alone except for the obvious spams).

No one is "insisting" on anything and it seems like a stretch to take something like this in the way you seem to be taking it. My post is clearly about how to do something with JOGL here... and this is certainly not a discussion, debate, or comparison-type thread.

I took some time to originally explain myself is quite a bit of detail and I'm obviously not as familiar with JOGL as all of you are, so I hope that it's understandable if the few sentences I've been receiving as responses (which I do appreciate!) are not immediately as clear to me as they may be to you.

gouessej wrote

This forum is a cool place to talk about JogAmp,

Then let's keep it that way, yes? It seemed to be going well until I came across this latest post of yours... and I'm not sure what I may've said that seemed to justify such a defensive reaction here, other than the fact that I mentioned a different library... which was simply mentioned for the sake of completeness and shouldn't cause any problems...

gouessej wrote

the aim is to avoid being bothered with useless flame wars and debates

Frankly speaking, I'm not sure where you see the "flame war and debate" here. Respectfully, if this has come across as some kind of "flame war" or "debate", then you should know that you've misunderstood/misinterpreted the thread and my posts from the start.

gouessej wrote

unlike in numerous other forums and I want to do my best to keep it cool and friendly for JogAmp users.

By saying that, you're implying that this thread is not "cool and friendly for JogAmp users". I thought it was already that way, but you seem to be interpreting things quite differently, and certainly not in the way that I intended.

First, I hope this clarifies my intention and how I intended my posts to be interpreted here. You seem to be taking a defensive posture simply because a different library was mentioned... which seems unreasonable and unjustified, IMHO.

Secondly, I'd understand if I had come here to ask questions about another lib, but that's not what I did. As already mentioned in one previous post, I'm not here to question or debate why JOGL decision "X" was made or not made in JOGL or anything of the sort. I'm not here "bashing" JOGL or trying to "promote" something else or anything like that.

I'm just trying to accomplish a goal that I (hopefully) described with enough clarity at first, but that I'm happy to further clarify if needed or if there're questions.

Since I'm not here for debates or anything of the sort, this is the only post I'll make regarding this topic and your reaction and I hope we can go back to talking JOGL, if you're still interested.

If what I'm trying to accomplish is not clear, please do ask away and I'll try to clarify as best I can.

Sven Gothel wrote

Just to make this long story maybe shorter:

It is 'just' about *work*.

Using the assisted API, i.e. GLAutoDrawable/GLEventListener
allows you to rely on our OpenGL + resources lifecycle support
and certain 'quirks' required to allow seamless operation on all
platforms, e.g. Android and OSX/AWT special cases.

Hi Sven,

I hear you. Perhaps the title is, in hindsight, a bit misleading. I understand why I want to use the assisted API and I wholeheartedly agree. To briefly illustrate the issue I'm trying to understand how to manage with JOGL, consider this:

// You have something like this in a client
RenderSystem rs = ...
rs.enableDepthTesting(true);

Internally, you'd expect this method to end up calling gl.glEnable(GL.GL_DEPTH_TEST) and might be tempted to start by writing GL4 gl = GLContext.getCurrentGL().getGL4() to use glEnable.

The client may want to issue this kind of call outside of void display(GLAutoDrawable) and does not take a GL instance as a parameter (i.e. not rs.enableDepthTesting(gl4, true) to keep the JOGL details hidden from the client.)

Of course the 'RenderSystem' would be implementing GLEventListener and, therefore, display(...), but the client is not expected to 'see' those and when display(...) is called automatically it ends up being called from a different thread anyway (i.e. AWT-Event-Queue) so it wouldn't work b/c being called directly, it would come from the main thread, etc. which would cause the GLContext.get* to return null or throw GLException for not being current.

Sven Gothel wrote

The assisted model also supports certain features like:
  - Suspend an GLContext (make offscreen, destroy drawable -> re-animate).
  - Swap On- offscreen drawable
  - ..

If you control GLDrawable/GLContext yourself,
you operate on a much lower level.
This gives you more freedom, but also implies a much
higher responsibility, since you can crash things more easily.
Everything is available for this low level hacking
and you can of course copy/paste our code pieces from
GLAutoDrawable, GLCanvas etc. However, maintenance might become
your burden here.
This approach may also end up in just reinventing the wheel :)

In case you dislike the assisted path b/c of a missing
but essential feature, we can discuss it and add it together.

I agree and definitely want to avoid doing that stuff. There's nothing I "dislike" about JOGL, if this is the way my posts have somehow been interpreted --quite the opposite, actually. I'm just trying to understand that the correct way of using JOGL for what I'm trying to achieve is and this is the part where I'm not sure my understanding has been that great.

I'm open to possibility that I may need to go back several "steps" and re-design something, but I need to better understand where my goal and JOGL's proper usage meet.

I apologize if there's anything I've said here that was not too clear and ended up causing the confusion that I think I had to clear up in this post and hopefully, I'll get the benefit of the doubt in the future.

Best regards,
-x

[EDIT: Finished a sentence.]

On 08/22/2015 04:28 AM, xghost [via jogamp] wrote:

(Ignoring the 'competitor' thingy, since I dunno)
Well, in case your API spec constraints the RenderSystem.display() call
appropriately, you may do maintain a local GL reference in the RenderSystem
instance. Your constraints simply must match the GLAutoDrawable semantics
here ofc, i.e. update GL ref at the latter GLAutoDrawable.display(drawable)
and clear it (null) afterwards. You may also want to ensure the user is not
calling RenderSystem.display() outside of that call flow ..

If it would be named 'RenderThing' one could assume similar semantics
as JOGL's GLAutoDrawable, which does hold all required associations,
i.e. drawable -> GL.
Hence exposing the current GL object for the time being (display call)
might not seem wrong in any way here.
However - one could now argue that even the GL object is JOGL,
which you work so hard to hide? :) Dunno ..
I meant 'dislike' purely in a technical context here :)
So 'unfavor' or better words may suit better.

>
> I'm open to possibility that I may need to go back several "steps" and
> re-design something, but I need to better understand where my goal and JOGL's
> proper usage meet.

Is your API free software, in such case we all may be able and willing
to share thoughts.

>
> I apologize if there's anything I've said here that was not too clear and
> ended up causing the confusion that I think I had to clear up in this post and
> hopefully, I'll get the benefit of the doubt in the future.

All good. If I am upset or anything, I always make sure the audience knows,
no reading between the lines is required then :)

Cheers, Sven

gouessej wrote

By the way, we don't have the same sense of humor. The next time I see a post insisting on mentioning repeatedly a competitor, I might ask others whether I should edit or delete it (we're in democracy, I don't make this kind of decision alone except for the obvious spams). This forum is a cool place to talk about JogAmp, the aim is to avoid being bothered with useless flame wars and debates unlike in numerous other forums and I want to do my best to keep it cool and friendly for JogAmp users.

Hi Gouessej,

I'd not like to interrupt the thread and going off-topic, may we continue this discussion in another place/thread?

elect wrote

I'd not like to interrupt the thread and going off-topic, may we continue this discussion in another place/thread?

Off-topic? Really?

xghost wrote

have also played around a bit with LWJGW3 --yes, I dare disturb you by mentioning a competitor :D--

(In my opinion) Yes, that's why I am not going to spend any further word on this here, just not the right place. Maybe in chat? :)