Subject: Response to the issues list from JSparrow From: Naruki Aruga Date: Wed, 02 Dec 1998 14:21:00 +0900 Hello all, I'm very sorry I'm so late. At last, we could respond the issues list. I'm afraid this is too late, but if you would take a look we are very happy. ISSUES: 1. Organization 1.1 How are the methods and constants organized into each class or interface? All constants are defined in OGLConstants interface. And all methods are defined in OGLStuff interface. Because OGLStuff extends OGLConstants, OGLStuff includes all constants and methods. Then, a class implements OGLStuff has complete capabilities of OpenGL. The classes implement OGLStuff are OGL, OGLCanvas, OGLPanel etc. Some object related GLU, GLUquadric, GLUnurbs and GLUtesselator are defined as interface. Constant: all constants (GL, GLU, GLUT etc.) Interface: - OGLConstants Method: all methods (GL, GLU, GLUT etc.) interface: - OGLStuff * OGLStuff extends OGLConstants class: - OGL - OGLCanvas - OGLPanel - etc. * all classes implement OGLStuff GLU objects: interface: - GLUquadric - GLUnurbs - GLUtesselator Users may use these interfaces and classes in various ways. Some exapmes are as follows: OGLConstants interface: In a class that implements OGLConstants interface, you can use any constants directory like C/C++. class MyClass implements OGLConstants { ... glBegin(GL_POLYGON); // not glBegin(ogl.GL_POLYGON); ... } OGL class: There are some styles to use OGL class. 1. Create a new class that extends OGL class MyOGL extends OGL { public void draw() { ... glVertex3f(1.0f, 2.0f, 3.0f); ... gluBeginSurface(theNurb); ... } } 2. Create a new class independently and use OGL object class MyClass { ... OGL ogl = new OGL(); ... ogl.glVertex3f(1.0f, 2.0f, 3.0f); ... ogl.gluBeginSurface(theNurb); ... } Of cource, you can use OGLStuff instead of OGL to define variables. OGLStuff ogl = new OGL(); It is easy to change OGL to other class implements OGLStuff later. OGLCanvas, OGLPanel: Create a new class extends OGLCanvas. Then, the source code in C/C++ may be required the minimum changes. public class My3DCanvas extends OGLCanvas { ... public void init() { ... glLightfv(GL_LIGHT0, GL_DIFFUSE, diffuse); ... } public void display() { glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); glutSolidTeapot(1.0); glFlush(); } ... } GLUquadric, GLUnurbs, GLUtesselator: These are interfaces. The usage of these interfaces are similar to C/C++. ... GLUnurbsObj theNurb; ... theNurb = gluNewNurbsRenderer(); ... gluBeginSurface(theNurb); gluNurbsSurface(theNurb, 8, knots, 8, knots, 4 * 3, 3, ctlpoints, 4, 4, GL_MAP2_VERTEX_3); gluEndSurface(theNurb); 1.2 How are the classes/interfaces organized into each package? In JSparrow, we currently use only one package. Some OpenGL engineers we talked were not required the package separation like GL, GLU, GLUT, GLX etc. But we don't believe only one package is the best. 1.3 Should there be separate packages for rendering and window system integration like what exists with OpenGL today? We know there are some platform specific problems. But currently, we don't have separate packages. And please see above. 2. Versioning 2.1 How is the native OpenGL API support queried? Same as OpenGL in C/C++. 2.2 How is the version compatibility between the app(let) and the native OpenGL libraries determined? Currently, we are trying to check and adopt the functionality internally. 3. Argument passing 3.1 How are Java Types mapped to C types? GLbyte -> byte GLenum -> int GLshort -> short GLbitfield -> int GLint -> int GLclampf -> float GLfloat -> float GLclampd -> double GLdouble -> double GLubyte -> byte GLboolean-> boolean GLushort -> short GLsizei -> int GLuint -> int 3.2 How are unsigned types converted? Just use signed types. 3.3 How does JavaGL handle pointers? We handle pointer as array and support multi-dimensional array type. C: glLoadMatrixf(GLfloat *m); JSparrow: glLoadMatrixf(float m[]); glLoadMatrixf(float m[][]); Pointer to GLvoid is handled as Object or suitable types of array. C: glCallLists(GLsizei n, GLenum type, GLvoid *lists); JSparrow: glCallLists(int n, int type, Object lists); or glCallLists(int n, int type, byte lists[]); glCallLists(int n, int type, short lists[]); glCallLists(int n, int type, int lists[]); glCallLists(int n, int type, float lists[]); Following three methods return String instead of pointer to GLubyte. glGetString(int name) gluGetString(int name) gluErrorString(int error) 3.4 How does JavaGL handle callbacks? Pointer to function is specified by the "name" string and the "object" that has the method C: gluNurbsCallback(theNurb, GLU_ERROR, nurbsError); Jsparrow: gluNurbsCallback(theNurb, GLU_ERROR, "nurbsError", this); 3.5 Enumerated types are heavily used in GL, GLU,GLX. How does JavaGL address this? We don't handle that types directly now. But I think this is a difficult issue. 3.6 How does JavaGL replace the capabilities of typedefs and #defines? Same as above. 3.7 Are GL commands overloaded or are all the variants implemented, i.e. glVertex(float xyz[]), glVertex(int xyz[]) or gl Vertex3fv(float xyz[]), glVertex3iv(int xyz[])? We implemented standard style. It is default I believe. But overloaded style is good too, of course. 4. Java Integration 4.1 What is the mechanism for the JavaGL app to access the system fonts? We didn't provide special method. There are some platform dependent problems. But for convenience, something may be required. 4.2 Class loading (do we need a Factory object or use the ClassLoader with system properties)? We have not supported any special mechanisms. Future issue for JSparrow. 4.3 How are differences in the JVM native interfaces handled? We are using Sun's JNI. In this level of development of JSparrow and the specification, it's enough we feel. 5. Window System 5.1 How do the JavaGL classes/packages interact with Swing, AWT graphics? Create rendering context with AWT and Swing component. jsCreateContext(Component) Both AWT and Swing are OK. OGLContext context = jsCreateContext(aPanel); jsMakeCurrent(aPanel, context); ... glBegin(GL_POLYGON); ... 5.2 How does JavaGL handle the problems with mixing heavy and light weight components? It's difficult but we are working to treat AWT and Swing components same. 5.3 How is double buffering handled? Set the double buffer capability and call swap buffers method. jsInitDisplayMode(GLUT_DOUBLE | GLUT_RGB); ... jsSwapBuffers(); 5.4 How is off screen rendering handled? We are implementing this feature. That is: "Create a rendering context for image and draw something on it." 5.5 How are overlays handled? We have no idea now. Future issue. 5.6 How are setting/Getting extended visual capabilities handled? We have no idea now. Please give us time... 5.7 How are ancillary buffers handled? We have no idea now. Please give us time... 5.8 How are index vs rgb frame buffers handled? Like double buffering. Same as C/C++ I think. 5.9 How is integration with other Java applications/libraries trying to render to the same window handled? Java's way. Java applications/libraries can render same window. Users shold consider timing and priority. 5.10 How is remote rendering handled? We don't have special method now. It's depend on window system like X Window. 5.11 Is a new protocol needed to support remote rendering? I would like to discuss more. 6. Multi threading 6.1 Are Java threads mapped 1:1 or n:1 with OS threads? Implementation dependent. 6.2 If not 1:1 how do we create thread safe JavaGL apps? Context management is important. We provide current context management mechanism. Use jsMakeCurrent(Component, OGLContext) method to lock and unlock current context. 7. Extensions 7.1 Is an extension mechanism per EXT or ARB extensions required? I think yes. We don't have special mechanism now but it's easy to add some method to OGL. OGL, OGLCanvas etc. are classes to extend. I would like to find a good solution. 7.2 Into what class(s) or interface(s) are extensions added? OGL, OGLCanvas etc. See above. 7.3 How are optional features in the spec such as the imaging subset handled? See above. 8. Context Management 8.1 How are shared objects (texture objects and display lists) handled? We support sharing display lists and textures as follows. jsCreateContext(Component, OGLContext) Create Context in this thread and share display lists with the context jsCreateContextAuto(Component, OGLContext) Create Context in AWT thread and share display lists with the context In addition, JSparrow allows context creation in any thread. Users may want to create context in their own thread and AWT thread. If Java thread and OS thread mapped 1:1, it's different completely. jsCreateContextAuto method cerates concrete context when component is mapped on screen. 9. Integration with Native OpenGL 9.1 Are calls to JavaGL required to have a 1:1 mapping to calls in the underlying OpenGL library? It's desirable. 9.2 How are is errors handled in JavaGL? Same as C/C++. But throwing exception is good way. We are considering now. 9.3 What is the behavior when the underlying native OpenGL does not support a feature in the JavaGL? JSparrow checks the compatibility when it is loaded and tries to provide same functionality in other way. If it's impossible, output warning message, throw exception etc. It's case dependent. If you want to propose features which do not fit into any of the categories above include them here. JSparrow is a straight and simple implementation of Java binding for OpenGL. It's very usefull for experiented OpenGL programmers in C/C++ because large part of exsisting source code do not require changes and the know-how is still valid greatly. The comparison of C/C++ and JSparrow source code is available at JSparrow web page. http://www.will.or.jp/~jsparrow/samples.html For novice to OpenGL and Java, they may need only the "Red Book" and some Java programing guide book. There are very few special case in JSparrow. This is our concept. Thank you very much. Naruki Aruga -- Naruki Aruga aruga@pfu.co.jp Research Center, PFU Limited, Tokyo, Japan Tel: +81-42-788-7628 Fax: +81-42-788-7697