Will the recommended text label rendering procedure change once 2D/3D mixing is available in Mustang?

My needs center around rendering an axis labeled with numeric values, but other typical uses would be to render objects and then put a descriptive label next to each, or to show two views and label one "View 1" and the other "View 2".  I currently use the GLUT bitmap fonts, but there are limited styles and sizes.  People with high-res screens have to squint, but the text looks a lot better than it does with the GLUT stroke font.

Ideally, the program would choose the font size to fit the screen area available at a given resolution.  The user could then choose different fonts or change the text size in the same way that is possible with Ctrl++ and Ctrl+- in Firefox.  I would like to be able center or right-justify the text, and get the metrics of the rendered string.

Would this type of feature be possible using the current procedure?  If so, has anyone written a class to automate it?

So, if I want to get something working in the next couple of weeks, would you recommend using Web Start to launch an installer application that copied files from the jar to the hard drive?  I'm sure a lot of people do this, but I wasn't sure if it was considered the correct way.

One thing I noticed was that the latest NetBeans IDE is installed using an exe file.  I'd expect that particular project to embrace Web Start as much as possible, so the fact that they use an exe makes me wonder if there are still some limitations of Web Start in regards to certain applications.  Perhaps they just haven't had time to convert their existing installer to Web Start.

Web Start documentation spends a lot of time on the case of launching from a web page which, at the very least, proves it is well named.  Many JOGL and Java  games probably fit in that category.  They don't really address how you would use it to install an office application or publishing package.  I had a hard time finding a "best practices", patterns, strategies, or complete examples for installing that type of application.  Like I said, I don't know if that's because it's more rare and unexplored thus far, or if it's a fundamental limitation.

Thanks for your help.  I'm pretty ignorant about Web Start and just started using it because this forum recommended it.  The documentation I read never addressed this topic and I didn't know about the other forums, but I'll check them out now.

I've just now gotten my application to install and run using Java Web Start.  Previously, I was unzipping a zip file and putting a shortcut to a batch file on the desktop.  I could drag files and drop them on the icon to open them with my application, because the file name would be passed as an argument by the batch file. 

When I drop a file on the shortcut placed by Web Start, it fails to open because the file doesn't get passed to my main method as an argument.  Is this a limitation of Web Start, or is there a way around it?  I would also like to be able to double click on a file and open it with my app, which works using the batch file, but not the Web Start shortcut.

Finally, some users have scripts that call utility classes that are located in my jar files.  When Web Start caches my jar, will it always be in the same accessible location?

Thanks.

OK, so my opinion has been registered.  I can live with the extra comma and zero.


One variant of glDrawPixels takes Buffer pixels and the other takes long pixels_buffer_offset .  What is the difference, and how would you convert JOGL code to the latter?

Thanks.

I just started the big switch to JSR 231, and I agree.  I appreciate all the work that has gone into this effort but, at the risk of seeming picky, I may as well speak up now, rather than not at all.  After reading the original slides a couple of years ago, where it seemed the best of the best would be pulled from previous bindings, I expected a more elegent solution.  When a new user decides to try OpenGL and Java together, they'll punch in a simple example from the Red Book, and they'll hit this.  After all that has been overcome to create these bindings, there isn't room for overloaded bindings that look like classic OpenGL?

-Xint and -server gave the same error.

I'll try to simplify the problem.  Thanks

I'm calling the drawing code from the display method.  I don't see any errors.  It just writes



I went back and tried running it with a previous version of my app using GL4Java and Java 1.4.2 and I got the same error.  I guess that indicates a problem with the video driver or OS?

> What are you debugging with?

JBuilder 2005.

The problem also happens running the program from a batch file.

Does it sound like a bug in the driver?

When running a certain class in my app I get the following error.  It happens at a call to glVertex2d() for a GL_QUAD_STRIP a few hundred iterations through a loop.  The arguments are array values which look OK when I check them in the debugger just before the fateful call.  Other classes I have which call glVertex2d seem to work fine.

Any ideas?



NVidia Quadro FX 3400
Driver 7.1.8.4, 2/24/2005

JOGL 1.1b10

I converted it as you said with the exception of keeping the buffer around from frame to frame.  I allocate a new one with every redraw and I quickly crash with an OutOfMemoryError.

I can change the code to reuse the buffer as long as the underlying data don't change, but if the user adds points to the underlying array, I will have to allocate a new, larger direct buffer.  How do I deallocate the old one to avoid a memory leak?

Well, I went on vacation for the holidays, then fought with upgrading to a new computer, and did some other work.  I finally got back to my "convert from GL4Java to JOGL" project last week.  I put in over a day switching the syntax from allocating arrays to allocating buffers.  Then I was finally able to compile the app without errors and I found that the optional Buffer array() method doesn't work with direct buffers and I apparently have to use get() and put().  Then I logged in to the JOGL forums and saw the previous post, which stated the same.  Great.

There are so many array accesses in my code.  Things like array1 = array2[j] + array3[k].  There is no way I'm changing all that to get() and put() on buffers.  It's time prohibitive, not to mention the significant chance of introducing errors.  My app isn't just an OpenGL app.  It does a lot of other things, which users relay on.  I can't drop everything and completely restructure my design, rewrite thousands of lines of code, and risk introducing bugs just to take advantage of slightly faster buffers.  I couldn't justify it for 10x faster buffers.

For compatability, I suggest offering a lower performance alternative that uses arrays with glVertexPointer the way GL4Java did.  For some people, such as myself, there isn't time for big rewrites like this.  The only time-effective alternative I see now is converting to for-loops with glVertex.  I may be able to convert the most performance critical code to Buffer and glVertexPointer as I get time later.

I do frequently access the array from outside the DataSeries object.  A quick count shows 26 classes that modify the array on their own.  The pattern I was using was for a file-parser class to allocate an array, read vertex data into the array, and then create a new DataSeries from the array.  Later, the user might add a vertex so an editor class would retrieve the array, allocate a new array that is one vertex larger, and copy the existing vertices.  The editor class would then call setArray(newArray) on the DataSeries to replace the old array.

I have a number of editor classes for different types of objects.  Some only allow modifications.  Others allow adding or deleting.  The DataSeries array is interleaved and holds any number of dimensions.  For example, it could hold a 2D Time-Value plot, a 3D X-Y-Z surface, a 5D Time-X-Y-Z-Scalar animation of an object that varies in location and color.

The DataSeries getArray() method can be changed easily from "return array" to "return buffer.array()".  But the DataSeries.setArray(float[]) method will have to be changed to setBuffer(Buffer), which means the parsers and editor classes will have to create a buffer for the DataSeries instead of an array.

I do handle some edit operations within the DataSeries class, but I try to keep them general like shift, multiply, resample, etc.  Some operations, such as frequency filtering, are more complex and should be in a separate class that operates on the DataSeries.

I've begun recoding them.  I'm about half way right now.

I am wondering about the strategy of using direct buffers with glVertexPointer.  With GL4Java, I had code like



where "series" was an instance of my DataSeries class, which basically wraps a float array and provides getArray() and setArray() along with other functionality.

JOGL uses a Buffer with glVertexPointer but, apparently, it requires it to be direct.  Therefore, FloatBuffer.wrap(array) does not work, as it creates a non-direct buffer.  I found that the following code works as a functional replacement



The problem is that the array can be any size.  On occasion, the application is memory bound because of it.  I'm not sure I like being forced to take an existing array, allocate new space for it, and copy it in, when space is already tight.

The only alternative I see is to rewrite the DataSeries class to be based around a Buffer instead of an array.  Any code that allocates an array and creates a DataSeries from it would need to be modified to allocate a Buffer instead.  This would be a considerable effort.  Is there any alternative to this?

Is there a reason that JOGL can't work with a non-direct buffer?  According to the Java documentation for ByteBuffer, "In general it is best to allocate direct buffers only when they yield a measureable gain in program performance."  Would giving the option of a non-direct wrapped array be a big drain on performance or be harder to implement?

Certain portions of the web site change with the times, but I was referring to the top level page at

http://jogl.dev.java.net/

which says "Welcome to the JOGL API Project!" and appears to be JOGL central.  But I don't think it ever changes.  I believe the front pages at opengl.org or mozilla.org are updated daily, so it gives you a reason to check back periodically.  Daily updates aren't necessary, but I think the front page for an evolving project should be as recent as any content within the site.  It would be nice if it said something like "The latest version is ___.  Download it _here_."  That just makes you feel like there's a little bit of life at the site and you're not wasting time reading a snapshot in time from a year ago.

I don't think the page reflects the current status of the project.  For instance, the getting started section seems to focus on building the library rather than using it, which gives the impression that its still in a construction phase and, perhaps, not fully ready for use beyond contributors and early adopters.  And the FAQ link at the top doesn't lead anywhere.  I eventually found my way to the downloads and the forum, but some potential users that heard about JSR 231 and want to check the status may get the wrong impression and give up.

Since the result returned didn't match, I wondered if there coud be a problem with the display driver.  I upgraded it from version 05050335 to 05050618, rebooted and, sure enough, my window popped up.  iresult is now 8235 and it passes the test.  My new output is:

Choosing window system's recommended choice of 0

GLCapabilities [DoubleBuffered: true, Stereo: false, HardwareAccelerated: true, DepthBits: 32, StencilBits: 0, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 0, Green Accum: 0, Blue Accum: 0, Alpha Accum: 0 ]


Sorry I didn't try that sooner.  Thanks for the help.

I changed both of the tests to the form you suggested, but formats 0-59 now fail the test



because iresults[7] == 8236

According to wglext.h,

GL.WGL_TYPE_RGBA_ARB == 0x202B == 8235
WGL_TYPE_COLORINDEX_ARB == 0x202C == 8236

Formats 60-83 now fail the test



because iresults[0] == 0

I've been wondering the same thing.  Ever since the Fahrenheit project, I've been rather skeptical to hear that "SGI has reached an agreement with Big Corp. X to bring graphics to the people and cause great rejoicing."  Hopefully, it is only delayed, but when the web page gets that out of date it does cause it to look a little dead.  Actually, the JOGL web page isn't updated very much, either.  All the activity seems to be on this forum.

I'm stepping through WindowsGLContext in the debugger.  I assume that's what you meant for me to do.  pfd2GLCapabilities never gets called.  In iattributes2GLCapabilities, for formats 0-59, it returns null for the code

       case GL.WGL_SUPPORT_OPENGL_ARB:
         if (iresults != GL.GL_TRUE)
           return null;
         break;

because
iresults[7] == 8236

For formats 60-83, it returns null for the code

       case GL.WGL_DRAW_TO_WINDOW_ARB:
         if (iresults != GL.GL_TRUE)
           return null;
         break;

because
iresults[0] == 0

Let me know what other information I can provide.
Thanks for helping.

OK, I finally got it to compile and run (after struggling with signed Jar security exceptions and getting the paths to the source and jars straight in JBuilder).  Here is the output:

Available 0: null
Available 1: null
Available 2: null
Available 3: null
Available 4: null
Available 5: null
Available 6: null
Available 7: null
Available 8: null
Available 9: null
Available 10: null
Available 11: null
Available 12: null
Available 13: null
Available 14: null
Available 15: null
Available 16: null
Available 17: null
Available 18: null
Available 19: null
Available 20: null
Available 21: null
Available 22: null
Available 23: null
Available 24: null
Available 25: null
Available 26: null
Available 27: null
Available 28: null
Available 29: null
Available 30: null
Available 31: null
Available 32: null
Available 33: null
Available 34: null
Available 35: null
Available 36: null
Available 37: null
Available 38: null
Available 39: null
Available 40: null
Available 41: null
Available 42: null
Available 43: null
Available 44: null
Available 45: null
Available 46: null
Available 47: null
Available 48: null
Available 49: null
Available 50: null
Available 51: null
Available 52: null
Available 53: null
Available 54: null
Available 55: null
Available 56: null
Available 57: null
Available 58: null
Available 59: null
Available 60: null
Available 61: null
Available 62: null
Available 63: null
Available 64: null
Available 65: null
Available 66: null
Available 67: null
Available 68: null
Available 69: null
Available 70: null
Available 71: null
Available 72: null
Available 73: null
Available 74: null
Available 75: null
Available 76: null
Available 77: null
Available 78: null
Available 79: null
Available 80: null
Available 81: null
Available 82: null
Available 83: null
Scores: [ -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999 ]

I am converting my code to JOGL from GL4Java.  I am getting an error at runtime for the following test code.  Do I need to create a custom glCap to pass in?  I'm running Win2K with a 3Dlabs Wildcat II 5110 at 1600x1200, 32 bit.  JDK 1.5.0,  JOGL 1.1b07 - November 19


 GLCanvas canvas =
     GLDrawableFactory.getFactory().createGLCanvas(
     new GLCapabilities());

 Frame testFrame = new Frame("TestFrame");
 testFrame.setSize( 512, 384 );
 testFrame.add( canvas );
 testFrame.setVisible(true);


Exception in thread "main" net.java.games.jogl.GLException: Unable to select one of the provided GLCapabilities
     at net.java.games.jogl.DefaultGLCapabilitiesChooser.chooseCapabilities(DefaultGLCapabilitiesChooser.java:214)
     at net.java.games.jogl.impl.windows.WindowsGLContext.choosePixelFormatAndCreateContext(WindowsGLContext.java:471)
     at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.create(WindowsOnscreenGLContext.java:211)
     at net.java.games.jogl.impl.windows.WindowsGLContext.makeCurrent(WindowsGLContext.java:135)
     at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.makeCurrent(WindowsOnscreenGLContext.java:110)
     at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:250)
     at net.java.games.jogl.GLCanvas.reshape(GLCanvas.java:112)
     at java.awt.Component.setBounds(Component.java:1847)
     at java.awt.BorderLayout.layoutContainer(BorderLayout.java:809)
     at java.awt.Container.layout(Container.java:1401)
     at java.awt.Container.doLayout(Container.java:1390)
     at java.awt.Container.validateTree(Container.java:1473)
     at java.awt.Container.validate(Container.java:1448)
     at java.awt.Window.show(Window.java:507)
     at java.awt.Component.show(Component.java:1300)
     at java.awt.Component.setVisible(Component.java:1253)

I never realized how language diverse this forum is.  Unfortunately, none of this helps me know how to say JOGL in Californian.  Maybe I'll just say it like Keanu Reeves and follow it up with "Dude!"

What is the proper way to pronounce JOGL?

Joe-Gull ?

Jaw-Gull ?

Juggle ?

Jay-Oh-Jee-El ?

Some other way?

:-/