Hi Don
Thanks again for your help on this one..
>The OMGraphicHandlerLayer sets the OMGraphicList returned from the
>prepare() method as the list. The default prepare() method, however,
>simply returns the OMGraphicList it gets from the getList() method,
>calling generate(getProjection()) on it first.
>
>You don't want to be using the ListResetProjectionChangePolicy on your
>layer, it will clear out the list when it receives the new projection
>before calling prepare(). You want to keep the default,
>StandardPCPolicy.
>I don't really have a good idea of how you are managing your
>OMGraphicList and what threads are updating that data. The prepare()
>method is usually used to handle projection changes in the SwingWorker
>thread, so the default implementation should be good enough for you if
>you are creating your OMGraphics in the layer constructor. If you know
>your layer is always going to be on the map, creating them in the layer
>init() method is also OK. I usually create OMGraphics in the prepare()
>method, so I don't create them until the layer is actually added to the
>map. A null OMGraphicList from getList() is my flag to know when the
>layer goes active, and initialization work needs to be done.
Ok I have managed to generate my OMGraphics in the prepare method as recommended.. I was overriding the OMGraphicList getlist method left in from my old 4.5.4 sample layer and this meant that a list already existed when prepare is called and hence the null test bypassed the generation of graphics etc.
I am managing my graphics lists in the following manner.. Please feel free to tell me if I'm going about it incorrectly!
Ok the initial graphics are as I said above generated in the prepare method.
New and updates for the existing graphics enter the system via various sources (serial data etc) and are handled in a separate thread to organise a list of messages specific to my layer.Periodically I check the list for new messages and then as a result either add a new OMGraphic to my lists or update the old graphic in the list.
This is all done outside the prepare method in my own methods.... umm perhaps I should be adding and updating within the prepare method.. I will try.
>It probably depends on how zoomed in you are, and what other layers are
>doing as well. Java rendering clipping could be slowing things down
>if your layer or other layers are really drawing things far off-screen.
Is there any way of limiting the java rendering so that no drawing is done off-screen?
>I run with a Java heap of 256 Mb, so I don't usually see
>OutOfMemoryExceptions that often. I think there are clipping
>improvements in the OMScalingRaster render algorithm in 4.6.1, which is
>being pushed out the door as I type this. But with scaling rasters,
>it's not always so much the size of the original image as it can also
>be the rendered size, too.
Forget this one .. I was having a bad day.. I forgot I had set up a new project for 4.6 and did not set my heap size to 700MB (JBuilder 6) in the run time environment variable table....Duh
So I'm getting there thanks to yourselves..
Regards
Mark.
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
--
[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 Tue Nov 02 2004 - 10:11:09 EST