Re: [OpenMap Users] OpenGL Panel considered?

From: Carsten . Madsen <>
Date: Fri, 26 May 2006 20:19:08 +0200

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 com.bbn.openmap.Layer;
import com.bbn.openmap.event.ProjectionEvent;

 * Simple example demoing how to use JOGL from within a OpenMap layer.
 * only works if run with -Dsun.java2d.opengl=False. You will need JOGL
 * 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
 * _at_author

public class JOGLLayer extends Layer {

    GLJPanel glcanvas;

    JOGLEventListener evtListener;

    public JOGLLayer() {
        try {
            GLCapabilities glcaps = new GLCapabilities();
            glcanvas = new GLJPanel(glcaps);
            evtListener = new JOGLEventListener();
            setLayout(new BorderLayout());
            add(glcanvas, BorderLayout.CENTER);
        } catch (Exception e) {

    public void projectionChanged(ProjectionEvent e) {
        System.out.println("JOGLLayer projectionChanged");

    // 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);
            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();



            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.glVertex2i((i * 10), 150);


        public void reshape(GLAutoDrawable arg0, int arg1, int arg2, int
                int arg4) {

        public void displayChanged(GLAutoDrawable arg0, boolean arg1,
                boolean arg2) {



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
>> 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 ""
>>> with the following text in the BODY of the message "unsubscribe
>>> openmap-users"]
> --
> [To unsubscribe to this list send an email to ""
> with the following text in the BODY of the message "unsubscribe
> openmap-users"]

[To unsubscribe to this list send an email to ""
with the following text in the BODY of the message "unsubscribe openmap-users"]
Received on Fri May 26 2006 - 14:20:10 EDT

This archive was generated by hypermail 2.3.0 : Tue Mar 28 2017 - 23:25:07 EDT