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?
If -Dsun.java2d.opengl=false JOGL/Swing integration is implemented via a
back buffer (OpenGL pbuffer) and pixel copy to Swing. This works ok with
a OM layer based on JOGL rendering. Running the OM/JOGL layer with
-Dsun.java2d.opengl=true however does not work. When
-Dsun.java2d.opengl=true all JOGL is done directly into the Swing back
buffer hence it will be very fast compared to copying pixels.
> 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.
Just running OM with mustang and -Dsun.java2d.opengl=true will improve
OM rendering speed a lot. If the JOGL integration can be made to work
things like animated symbols etc should be a snap to implement and
perform as well as your graphics card.
/carsten
>
> - 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 - 11:54:39 EDT