jogl API feedback requested for JSR 231

OpenGL Development JOGL Development
#61

[quote]In addition to things I have mentioned in my first post (security), I wonder if it would be possible to integrate java images with opengl calls - so ImageIO could be used directly for feeding textures to opengl.

There is also a big question of updating the official binding. With JOGL, in theory you could just regenerate it every time new glext.h appeared. With official libraries, it would be very bad to have to wait more than few weeks for new extensions to appear in GL.java - so some kind of process has to be set up to keep it up to date.
[/quote]
I think the main GL class should not extend the OpenGL API any more than it has to, so I don’t think we should integrate ImageIO with the javax.media.opengl.GL class. However, I do think you are correct that it would be nice to have some functions of convenience that leverage the power of Java with the OpenGL API. Perhaps a set of utility classes in a package named javax.media.opengl.util could do it. This would be a separate set of classes that do things like load textures and models, or perhaps even contain mesh utilities like DX has. The nice thing about this approach is that it doesn’t muddy the core OpenGL API but contains the higher level functions of convenience that most of us would like. Of course, this is extra work. It might be better to provide these util functions as an open source community project instead (Of course, this would require a non-javax package name).

What do you think, abies (or anyone else)?

I second the motion for having an official process for getting new extensions pulled into the bindings in short order.

#62

I agree with shaddam_IV on this; reuse of existing image I/O classes is good, but it has a more ‘rightful’ place in an opengl.util package. I’m not sure if going so far as to keep image I/O outside of the JSR 231 API is a good idea though. It’s true that we should be careful not to turn part of the API into a complete 3D engine, but something like image I/O can certainly be branded ‘core functionality’ for any 3D API.

Agreed, waiting too long on new extensions would very likely hurt JOGL popularity (although one or two weeks aren’t going to kill any of us, are they?).

#63

Uh, trance. I don’t think you are following the
argument correctly. You seem to think the people
who want to be consistent want to change things.
Please see www.dictionary.com for a definition of
the word “consistent.” That is exactly the
opposite of what we are saying.

www.dictonary.com:

-----------
Entry: consistent
Function: adjective
Definition: compatible
Synonyms: accordant, according to, agreeable, agreeing, coherent, compatible, conforming with, congenial, congruous, consonant, equable, harmonious, like, logical, matching, sympathetic
Antonyms: disagreeing, incompatible, incongruous, inconsistent
Concept: correspondence
Source: Roget’s Interactive Thesaurus, First Edition (v 1.0.0)
Copyright © 2004 by Lexico Publishing Group, LLC. All rights reserved.
-----------

and? nothing has changed …

We are suggesting maintaining exact names across languages.

no. “some” ppl. other ones had a discussion about the “_gl”. look at the first page of this thread. look at the reactions. and: i was delegated to write here, you can see my own thread in this forum. so it seems there are several topics …

and my reaction to “your” topic: no problem with that. but this was not “my” topic. so: your “consistence” targets “another topic” … its similar, it could be mixed, but it not the same.

furthermore: there is no combination where “gl._gl” makes something consistent. didnt you read what i had written? my argues were - as a side aspect - also valid for “your discussion” and naming conventions in general. … it would not be senseful keeping java consistent AND makes no sense keeping consistence between two different languages AND makes no sense keeping java to GL consistent. the reason: it is a product of a conversion which creates something “new” … this leads to a general inconsistence … i simply want avoid such trends … thats all.

//Remember, the "pro-renaming argument fails to
//address the issue of naming your GLDrawable
//something besides “gl”, which has great potential to
//confuse others.

no. great potential to confuse means in forums often only that someone thinks that it should be to keep an argumentation.

“Drawable” has a meaning. what means “Drawable”? what are the “real” differences between a “Drawable” from an openGL package to any other java apis? what about the addressing in other situations? how do you handle and name “methods” in general? … i see no problem … only a problem which was made because a bad conversion … not only your problem: “JFrame” (swing) is also no good solution … you have a “swing”-ui or any other api and inside should be a “Frame”… a frame from swing, a frame from ui XY… but no “XFRame”, “Frame”, “JFrame”, “GLFrame”…

sometimes… - thats life - there are good reasons to break consistence … but not in those simple cases …

note: you can say “the arm of a human” … “humans arm” … but avoid things like “humans arm of a human” … in computer languages, in offline life, general :slight_smile: (exceptions are hacking languages with lives from chaotic combinations. thats ok, i like chaos too, but thats not java) … … earlier or later you will produce more and more inconsistence … unnecessary overhead … “Drawable” means “Drawable”. thats all. “get” means “get” … there is no reason to produce “gl_get”, “xy_get”, “bla_get” … “gl.” adresses enough and gives no confusion … (api design play another role here… lalala.bla.blubb.quak.Drawable is another thing as “gl.bla.Drawable”)

… so please keep things simple… forget ALL “_gl”, “GL” … that means in some situations a bnit more work but in thousand other cases more consistence and less work. “implements” or creating new objects are exceptions … masses of "_gl"s in every line not!

#64

My requests for JOGL/JSR 231:

  1. Exposed swapbuffers so we’re not forced to use the Animator (I understand this has already been implemented? yay!)

  2. Some way of making it work in an applet for someone who has installed a recent version of java without having to purchase a verisign certificate. Applets, suck, I know. But 3d on webpages = teh sexy. :wink:

  3. Stability / Less jvm level crashes. I’ve had some problems with certain hardware crashing totally when I try using PBuffers. This wouldn’t be a problem if it just threw an exception, but right now it crashes and dumps a log file to disk.

Other than that, I think it’s fine as it is. Sure, it would make more sense to have “gl.vertex3f” instead of “gl.glVertex3f”, but it doesn’t really matter either way.

#65

Gregory Pierce had some good ideas that I’m not sure have been mentioned.

I think one of the mains ones was brought up early on in the thread though…

It makes no sense for there to be multiple OpenGL bindings, there is only one OpenGL API, and usually only one implementation available at the system level. So abstracting away the dependency on AWT,SWT,LWJGL etc. make a lot of sense.
Have bindings that deal with a GL context and a way to get that context from AWT windows, Swing windows, SWT windows, LWJGL screens, etc.

This will allow for better interoperability between the various APIs that we would possibly want to use.

Each of LWJGL, SWT, AWT etc. have different philosophies but stupidly their have been separate OpenGL bindings made for each, when OpenGL is one thing that isn’t actually different between them… What a waste of effort. Let the various APIs have their differences, but let’s keep the stuff that should be shareable between them so that it is actually shareable (hint GL context).

P.S. Just to be fair I have to say that I haven’t actually used any of the OpenGL bindings yet. But I expect to at some point and I would rather not have to deal with a mess when I get there.

#66

I don’t mind too much about the whole prefix issue. Pick one and go with it.

My top issues:

  1. A single API standard that works across all the GL bindings (LWGL, JOGL etc) - we did it for XML parsers, now lets do it for OpenGL. I shouldn’t be tied to a single implementation because of the standard.

  2. SWT Support, or at least make it easy for someone to provide it. Distance the JSR from the AWT.

  3. My app does smart swapping, using a glCopyArea when only a small portion of the back buffer is dirty. For this I need manual glSwapBuffers control.

  4. glVertexPointer should accept non-direct FloatBuffers and float arrays, and not be restricted to direct FloatBuffers. Ditto glColorPointer.

  5. Some specification of expected behavior if you call native code that executes GL routines. Some of my rendering code is owned by a third party and they won’t port to Java.

  6. My one naming issue: GLUtesselatorCallback and its brethren. By instinct I type GLUTesselatorCallback. The GLUtesselatorCallback just feels plain wrong. And on that topic, should GLUtesselatorCallbackAdapter be just be GLUTesselatorAdapter. Cf. MouseAdapter.

Jon

#67

In order of priority:

  1. An specification that is thoroughly specified, not just a copy of the (non-existant in many cases) Javadoc. If I want to implement my own version of the specification, the document should be clear and unambiguous enough that I can do it without asking questions.

  2. Scalable API definition. It’s impossible to extend the API with vendor specific additions right now. Considering that OpenGL gets extended far faster than the JSR process ever does, this restricts us to only very slow changes. If a vendor introduces a new set of APIs and I want to limit my application to those APIs, let me. Get out of my way and let me do what I want. It should have interfaces for the core OpenGL spec and then extension interfaces for each vendor etc.

  3. Get rid of lazy instantiation (or at least select a mode where it is immediate). Trying to do realtime graphics apps using offscreen buffers is impossible right now if you need to do one-off rendering to a buffer and synchronise it to the current frame.

  4. Textures should be able to take NIOBuffers. Right now we still have to pull the images into Java land, when we don’t really need to.

  5. *Pointer methods should take non-direct buffers

#68

[quote]…abstracting away the dependency on AWT,SWT,LWJGL etc. make a lot of sense…
[/quote]
Although this sounds desirable, I wonder how feasible it is when it comes to implementation. If each API has its own version of a native rendering surface, I think it will be very impractical to develop methods for handling every single custom API rendering surface.

IMHO, because the bindings are meant to be a part of the official Java platform, we should only have “official” support for the official Java platform APIs. Namely, Swing and AWT. If unofficial APIs, such as SWT, want to use the bindings they should conform to the official OpenGL bindings, not the other way around.

In any event, most (all?) non-standard APIs (including SWT) have methods for playing well with basic Swing or AWT components. Since GLDrawables are derived from java.awt.Canvas, these APIs should work with JOGL anyways.

#69

[quote]Get rid of lazy instantiation (or at least select a mode where it is immediate). Trying to do realtime graphics apps using offscreen buffers is impossible right now if you need to do one-off rendering to a buffer and synchronise it to the current frame.
[/quote]
I don’t know the technical hurdles involved with this, but I totally agree.

[quote]*Pointer methods should take non-direct buffers
[/quote]
After having attended the excellent Java gaming technologies tutorial at GDC this year, I believe I understand the reasons for using direct buffers. As I understand it, a native OS allocation is needed to protect the memory from getting munged by the GC. This requires direct buffers, which allocate from system memory rather than VM memory. Perhaps one of the gods of JOGL here can verify this summary. This being the case, direct buffers are what we need. Besides, direct buffers aren’t hard to work with.

#70

Non-direct buffer support is a waste of time.

Array support is probably a waste of time too, though it might look convenient.

I am still highly concerned about JOGL being touted as the “standard” J2SE GL binding, when so many voices are trying to pull it in so many directions and already people are worried about the glacial speed of development. Clarify all these issues in a clear project mission statement with discrete objectives and then set about presenting solutions to achieve those objectives.

Cas :slight_smile:

#71

[quote] Posted by: Markus_Persson
2) Some way of making it work in an applet for someone who has installed a recent version of java without having to purchase a verisign certificate. Applets, suck, I know. But 3d on webpages = teh sexy.
[/quote]
AFAIK you can do this with JNLP. It supports applet which you can self-sign and request the user has to accept them at least once.

[quote] shaddam_IV wrote:
IMHO, because the bindings are meant to be a part of the official Java platform, we should only have “official” support for the official Java platform APIs. Namely, Swing and AWT. If unofficial APIs, such as SWT, want to use the bindings they should conform to the official OpenGL bindings, not the other way around.
[/quote]
Don’t say this aloud when cas reads that, a holy war far greater than the ‘naming scheme djihad’ breaks out … :smiley:

Btw. cas has made suggestions already how this API independence could be achieved. As I have understood him it involves writing an SPI and let others implementing it. So its up the ones which really want SWT, lwjgl support to provide a SPI implementation.

In fact I think that the SPI approach is really a good one. I don’t know about the implementors responsibilities but if it can bring JOGL to ANY JavaVM (like the SPI for javax.sound) then this should be the way to go.

(I am looking forward to see a JOGL implementation for my favorite OS. see signature :slight_smile: )

– EDIT: ah cas was faster than me.

#72

There now exists, in the CVS of the LWJGL, three new classes in org.lwjgl.util, which show how you can address all of the JOGL issues.

There’s a GLI interface, which is an interface describing all the GL commands, including the ARB and EXT ones we support.

There’s a GLImpl class, which is a class which implements GLI, and delegates all its calls to another utility class called GL, which is simply a static class which has all of LWJGL’s GL methods in it from 1.1->1.5 and the EXT and ARB ones.

You might not necessarily agree with what commands are in GLI but the fact of the matter is it took 5 minutes with Eclipse and Textpad to make these classes and it shows everyone just how vacuous the whole GL naming argument actually is. Code to GLI and you can use both JOGL and LWJGL. Create a GLIWithNoGLs interface and you can rename all the methods to remove the gl prefix from the commands. Create a GLWithNoGLsAndCapsFirstLetter and rename all the methods to use no gl prefix and a caps first letter.

What’s the cost? 5 minutes of your time.

The arguments about the GL bindings need to be about the consistent way in which the binding is interacted with, not about the naming of the commands.

By consistent interaction I mean:

  • are arrays supported as parameters
  • are non-direct buffers supported as parameters
  • are buffer limits and positions respected
  • are typesafe enums used or ints
  • are doubles supported
  • are methods which are pointlessly inefficient in Java supported
  • which GL extensions are supported

If JOGL wants to become a standard I suggest it works on the principle of defining an interface like GLI and defining the answers to those questions.

Cas :slight_smile:

#73

It has already been done in the field. From what i’ve heard it is extremely simple.

[quote]If each API has its own version of a native rendering surface, I think it will be very impractical to develop methods for handling every single custom API rendering surface.
[/quote]
Yes, but that CAN’T be the case. On each platform openGL works a certain way there is a native OpenGL context that the platforms openGL implementation must work with. Since every OpenGL binding is ultimately forced to go through the platforms native OpenGL there is automatically a common data structure to represent the surface. The abstractions that the individual implementations provide (AWT, Swing, SWT, LWJGL) can remain as it is.

#74

This is pretty much what I meant by recognizing the difference between the public JSR 231 API (aka: the pure Java interface for the OpenGL world) and the implementation (how JOGL/LWJGL/wha’eva handles the API internally).

If the official API sticks to all the ‘fancy’ rules on Java design (which would include preventing C artefacts leaking into Java - that is not just a naming issue), then I couldn’t care less about how an implementation deals with it internally (except I’d like it to be robust and fast, of course :P).

It seems people consider the garbage collector to be somewhat too hostile for this to be feasible. I guess having something like a ‘programmable’ garbage collector (ie: one that doesn’t collect and delete at any moment it bloody well pleases) would have been nice. Perhaps that’s just too close to C++?

#75

[quote]By consistent interaction I mean:

  • are arrays supported as parameters
  • are non-direct buffers supported as parameters
  • are buffer limits and positions respected
  • are typesafe enums used or ints
  • are doubles supported
  • are methods which are pointlessly inefficient in Java supported
  • which GL extensions are supported
    [/quote]
    Answers for JOGL, in order, are
  • yes, where possible (i.e., where the OpenGL state machine doesn’t require long-term “pinned” storage)
  • no, all uses of buffers are direct buffers
  • unclear what you mean; JOGL does not bounds-check buffers going out to OpenGL, as doing so would require semantic information about how much storage will be examined by the OpenGL state machine. Additionally, the base address of direct buffers is passed down to C, not base address + position. The user must slice their buffers to get interior pointers. I believe this is less confusing than other behavior, where put() operations may change results.
  • ints, not typesafe enums
  • yes, doubles are supported
  • JOGL exposes all of the methods defined by the OpenGL standard
  • all of the OpenGL extensions that were present the last time we updated JOGL’s header files are supported, including ARB_vertex_buffer_object, ARB_vertex_program, and ARB_fragment_program. Full OpenGL 1.5 support is coming.

[quote]If JOGL wants to become a standard I suggest it works on the principle of defining an interface like GLI and defining the answers to those questions.
[/quote]
JOGL has always been designed around the use of interfaces to avoid tying the library and users’ code to any particular implementation (and, in fact, to any particular window system). Its GL and GLDrawable interfaces have multiple implementations, and its GLEventListener interface is just that, an interface, not an abstract class, to give users flexibility in their interactions with the library.

#76

Method naming is obviously a sensitive topic for a lot of people. With the automatic generation of most of jogl from the C header files, I think it would be fairly easy to generate libraries with various naming conventions (gl.glVertex3f(…), gl.vertex3f(…), gl.vertex(…), etc.)

My request:

Please build a few different versions and actually TRY USING THEM before making this decision. Do a little usability testing with people of different skill levels (combinations of java and opengl experience) and see how they do. Try a few different popular development environments to see how modern autocomplete features affect productivity. In other words see what works.

Deciding this in the abstract is a surefire way to come up with a righteous position that just annoys people.

(my suspicion: no one will miss the extra ‘gl’ prefix on method names once they’ve tried it, but I’ll let the tests decide)

(edited for spelling)

#77

Our top prioirity is that JOGL be finalized by the end of the year. We need a binding that is going to be stable for a release Q105. Second is being able to access all ARB extensions without a need to revise the spec. For example, the spec should state how the mapping is performed, rather than enumeratiing the current mapping. We are assuming that it supports both Windows and Mac so that is a given, but prebuilt binaries for both would be a high priority.

#78

In my experience most easy is type:
gl.vertex(1.0, 2.0, 3.1);
second easiest is:
gl.vertex3f(1f, 2f. 3.3f);

Ihave moded JOGL a little and used it over two weeks, so…

#79

please add this to the GL class:

  final static int GL_TEXTURE_STORAGE_HINT_APPLE = 0x85BC;
#80

Could you provide a pointer to a header file that contains this extension? Or if it’s in the extension registry, what’s the extension number?