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"]
Received on Fri May 26 2006 - 11:37:54 EDT