Here you go. If anybody manages to get this running with
-Dsun.java2d.opengl=true please post the solution. I know it is related
to the OM paint policy etc but there is some magic to it that I just do
not get. Play around with the paint method plus -Dsun.java2d.opengl=true
to see "it". Rendering speed is quit good even with
-Dsun.java2d.opengl=false except for resizing.
Somebody with a better understanding of the OM paint optimizations than
I may get it.
The example is here. Instructions are in the javadoc part:
import java.awt.BorderLayout;
import javax.media.opengl.GL;
import javax.media.opengl.GLAutoDrawable;
import javax.media.opengl.GLCapabilities;
import javax.media.opengl.GLDrawable;
import javax.media.opengl.GLEventListener;
import javax.media.opengl.GLJPanel;
import javax.media.opengl.glu.GLU;
import com.bbn.openmap.Layer;
import com.bbn.openmap.event.ProjectionEvent;
/**
* Simple example demoing how to use JOGL from within a OpenMap layer.
Currently
* only works if run with -Dsun.java2d.opengl=False. You will need JOGL
*
https://jogl.dev.java.net/ installed and jdk 1.6 or later to run
this. To use it add
* something like
*
* openmap.layers=date jgl
* openmap.startUpLayers=date jgl
* jgl.class=dk.navicon.ais.utils.gui.JOGLLayer
* jgl.prettyName=JOGL Test
*
* openmap.properties
*
* _at_author com_at_navicon.dk
*
*/
public class JOGLLayer extends Layer {
GLJPanel glcanvas;
JOGLEventListener evtListener;
public JOGLLayer() {
try {
GLCapabilities glcaps = new GLCapabilities();
glcanvas = new GLJPanel(glcaps);
evtListener = new JOGLEventListener();
glcanvas.addGLEventListener(evtListener);
setLayout(new BorderLayout());
add(glcanvas, BorderLayout.CENTER);
} catch (Exception e) {
e.printStackTrace();
}
}
public void projectionChanged(ProjectionEvent e) {
System.out.println("JOGLLayer projectionChanged");
super.repaint();
}
// public synchronized void paint(Graphics g) {
// super.paint(g);
// System.out.println("JOGLLayer paint");
// glcanvas.paint(g);
// }
class JOGLEventListener implements GLEventListener {
public void reshape(GLDrawable drawable, int x, int y, int width,
int height) {
}
public void displayChanged(GLDrawable drawable, boolean modeChanged,
boolean deviceChanged) {
}
public void init(GLAutoDrawable gld) {
System.out.println("JOGLEventListeer init");
GL gl = gld.getGL();
gl.glClearColor(0.0f, 0.0f, 0.0f, 1.0f);
gl.glViewport(0, 0, 500, 300);
gl.glMatrixMode(GL.GL_PROJECTION);
gl.glLoadIdentity();
glu.gluOrtho2D(0.0, 500.0, 0.0, 300.0);
}
GLU glu = new GLU();
public void display(GLAutoDrawable gld) {
System.out.println("JOGLEventListener display");
float red = 0.0f;
float green = 0.0f;
float blue = 0.0f;
GL gl = gld.getGL();
gl.glClear(GL.GL_COLOR_BUFFER_BIT);
gl.glPointSize(5.0f);
for (int i = 0; i < 50; i++) {
red -= .09f;
green -= .12f;
blue -= .15f;
if (red < 0.15)
red = 1.0f;
if (green < 0.15)
green = 1.0f;
if (blue < 0.15)
blue = 1.0f;
gl.glColor3f(red, green, blue);
gl.glBegin(GL.GL_POINTS);
gl.glVertex2i((i * 10), 150);
gl.glEnd();
}
}
public void reshape(GLAutoDrawable arg0, int arg1, int arg2, int
arg3,
int arg4) {
}
public void displayChanged(GLAutoDrawable arg0, boolean arg1,
boolean arg2) {
}
}
}
regards
/carsten
Don Dietrick wrote:
> Thanks, I didn't know about this.
>
> On May 26, 2006, at 11:23 AM, Carsten Ø. Madsen wrote:
>
>> In the beta 1.6's versions after b51 there is a OpenGL-based Java2D
>> pipeline. Just run with -Dsun.java2d.opengl=True when using a
>> mustang release.
>>
>> Quote: "In Mustang b51, we made some minor enhancements to Java2D
>> that allow JOGL's GLJPanel implementation to render directly into
>> the Swing backbuffer when the OpenGL-based Java2D pipeline is
>> enabled (see 6309763). While it was certainly possible before to use
>> JOGL in a Swing application, it required a number of intermediate
>> steps to get the proper rendering on the screen in the correct
>> order. With these minor changes in place, JOGL is now able to use an
>> optimized codepath so that rendering goes directly into the
>> OpenGL-enabled Swing backbuffer, effectively bypassing all those
>> slow intermediate steps."
>>
>> More info here http://weblogs.java.net/blog/campbell/archive/
>> 2005/09/java2djogl_inte_1.html
>>
>> We have a OM layer running with JOGL/1.6 but it does not work when
>> running with optimized OpenGL rendering due to problems with how OM
>> manages overriding paint (we think). I will try to post an example
>> later.
>
>
> What do you mean by optimized OpenGL rendering? Is that different
> than standard OpenGL rendering, or is all OpenGL rendering optimized?
>
> I guess I'm wondering if the current way OpenMap layers render just
> doesn't work at all, or just under certain settings.
>
> We're always interested in making changes to accommodate any
> rendering speedups.
>
> - Dom
>
>
>
>
>
>>
>> Don Dietrick wrote:
>>
>>> Hi Thomas,
>>>
>>> You could do this, but the default OpenMap application isn't set
>>> up for it. You could use OpenMap components to create textures
>>> for overlay into 3d space objects, for instance. We've done this
>>> on some internal projects here at BBN. Direct rendering is more
>>> complicated because of the separation between the OpenMap Swing's
>>> lightweight Java objects and the need for, say, OpenGL's need to
>>> deal with heavyweight Java objects. I think there's been some
>>> progress on lightweight-heavyweight integration, but it's been a
>>> while since I looked into it and someone else can chime in on that.
>>>
>>> On May 26, 2006, at 1:00 AM, Thomas Schar wrote:
>>>
>>>> Hi,
>>>>
>>>> I was just wondering if there is any benefit to openmap makubg
>>>> use of 3d hardware accel rendering? We are investigating the use
>>>> of openmap in a near real-time update (ie. military situational
>>>> awareness display) scenario and when combined with a single CADRG
>>>> (RpfLayer), and a few (<20) OMGraphics, the rendering is too slow.
>>>>
>>>> < details >
>>>> (talking between 2-10 secs to perform a pan and/or zoom -- this
>>>> is on a Athlon64 2.x with 1 GB ram). The CADRG full data set is
>>>> largish (450MB) but only a very small amount of the map is shown
>>>> (say <1%). I'm not sure exactly how the CADRG is broken up into
>>>> tile/cells, but it's an official NIMA dataset, so I'm hoping that
>>>> it has been generated reasonably well.
>>>> < /details >
>>>
>>>
>>> Sounds like something else is going on. What's your OS and jdk
>>> version? If you are using X Windows and running OpenMap remotely
>>> with any transparency on the map, that will hurt performance a
>>> lot. The GraticuleLayer has transparency set in it's lines by
>>> default, so that's one thing that might be happening?
>>>
>>> Each CADRG frame is broken into 36 (6x6) 256x256 pixel subframe
>>> images, in terms of how it looks at the chart's native
>>> resolution. When you zoom out, more frames are needed, obviously,
>>> and you might want to change cache settings to see how that
>>> helps. The caches are set to hold 4 frames and 40 subframes, and
>>> if you start blowing that on pans, you'll start waiting for I/O.
>>> If you keep the map close to the native scale of the images the
>>> response should be very quick. There are property settings for
>>> these cache parameters, more information is in the javadocs for
>>> the layer.
>>>
>>> The size of the data set isn't that important wrt/performance, but
>>> the number of RPF directories is. Also, using a data set
>>> available via NFS will also be slower. You can use the palette of
>>> the layer to turn the attributes on for a RpfLayer an see where
>>> the subframes are. If you zoom to the native level of the
>>> displayed chart, you'll see the other information of the subframe,
>>> like which frame it is from, etc.
>>>
>>> Also, do you have other layers on behind the CADRG? If you have a
>>> Shape file political boundary on, it's still getting rendered even
>>> though it's behind the CADRG, and that be just one more thing the
>>> cpu has to prepare for rendering.
>>>
>>> You can also think about marking layers as 'background', which
>>> will place them in a special image buffer in the
>>> BufferedLayerMapBean (the one used by default). This won't help
>>> for pans and zooms, but performance of animation over a stable map
>>> will be greatly enhanced. You can test this by adding an
>>> AnimationTester to the OpenMap application
>>> (com.bbn.openmap.graphicLoader.AnimationTester to the
>>> openmap.components property, along with a
>>> GraphicLoaderConnector). If you bring up the palette that gets
>>> created for the AnimationTester, you can add sprites and change
>>> timer settings to make them wander around the map.
>>>
>>>> Anyway, I was playing with ways of optimising the performance,
>>>> when I just sort of wondered why 3d hardware accelearation isn't
>>>> used more. Is this due to the immaturity of jogl/j3d/lwjgl
>>>> libraries or because the hardware doesn't provide any benefit?
>>>
>>>
>>> Java takes advantage of using hardware acceleration of the video
>>> card when it can, but using the 3d acceleration is a different
>>> beast. You have to define the stuff you want rendered in terms
>>> the hardware understands, in 3d space, and compile those objects
>>> into the 3d scene. All of the OMGraphic map objects that layers
>>> use render themselves into the Graphics2D object of the parent
>>> component. Like I mentioned above, you could get the OMGraphics
>>> to rendering into an image used as texture for a 3d object, but
>>> you'd have to change the architecture of the application to work
>>> that way.
>>>
>>> Regards,
>>>
>>> Don
>>>
>>>
>>>
>>> --
>>> [To unsubscribe to this list send an email to "majdart_at_bbn.com"
>>> with the following text in the BODY of the message "unsubscribe
>>> openmap-users"]
>>
>
> --
> [To unsubscribe to this list send an email to "majdart_at_bbn.com"
> with the following text in the BODY of the message "unsubscribe
> openmap-users"]
--
[To unsubscribe to this list send an email to "majdart_at_bbn.com"
with the following text in the BODY of the message "unsubscribe openmap-users"]
Received on Fri May 26 2006 - 14:20:10 EDT