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 <
https://mustang.dev.java.net/> b51, we made some
minor enhancements to Java2D that allow JOGL
<
https://jogl.dev.java.net>'s GLJPanel implementation to render directly
into the Swing backbuffer when the OpenGL-based Java2D pipeline
<
http://weblogs.java.net/blog/campbell/archive/2005/07/strcrazier_perf.html>
is enabled (see 6309763
<
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=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.
regards
/carsten
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"]
Received on Fri May 26 2006 - 11:25:03 EDT