Agenda:
1) udig 1.2-M2 testing
2) rendering of invisible layers
3) feature cache implementation approach
(7:24:45 AM) jgarnett: (but I forgot to send out a reminder yesterday)
(7:24:54 AM) jgarnett: so I am not sure how many people we will scare up
(7:25:00 AM) emily_g: well i have two questions
(7:25:06 AM) jgarnett: the 1.2-M2 release is ready; but we are bogging down on linux testing
(7:25:17 AM) jgarnett: sure ... I will send out a reminder email
(7:25:23 AM) emily_g: & I took the 1.2-M2 release and went most of the way through walkthrough 1
(7:25:31 AM) emily_g: I have a comments/issues
(7:25:38 AM) emily_g: when I'm finished I'll email the list
(7:25:55 AM) jgarnett: oh cool!
(7:26:41 AM) jgarnett: also moovida emails me that he committed a strange fix for the linux path issues (filename paths were getting garbled between runs of udig - mostly due to some crazy "relative path" code they put in at one stage)
(7:27:29 AM) jgarnett: aside: you were able to update and build recently right?
(7:27:39 AM) jgarnett: I still have some reports of people with build trouble
(7:28:26 AM) emily_g: I had some weird problems; I updated; refreshed; and did a build and had a whole bunch of errors. I cleaned/refreshed/closed eclipse and somehow it started working magically
(7:29:05 AM) jgarnett: hrm
(7:29:34 AM) jgarnett: I watched John Hudson do a similar thing; it appears as if changing the MANIFEST.MF
(7:29:59 AM) jgarnett: confuses poor eclipse; even when you do a refresh on the net.refractions.udig.libs project folder.
(7:30:06 AM) jgarnett: okay on to your questions
(7:30:22 AM) jgarnett has changed the topic to: 1) udig1.2-M2 2) questions and answer
(7:30:51 AM) emily_g: rendering; it looks to me like the renderer renders both visible and non-visible layers then only composes the visible layers
(7:31:09 AM) emily_g: I was wondering what the decision was behind rendering all layers
(7:31:11 AM) emily_g: all the time
(7:31:15 AM) emily_g: and not just the visible ones
(7:31:46 AM) emily_g: quiet often if I have a layer that I know will be slow to render (lots of features) I'll want to zoom in to a particular spot then make it visible and watch it render
(7:38:17 AM) jgarnett: thinking
(7:38:38 AM) jgarnett: I want to see all the renderers composed
(7:38:56 AM) jgarnett: so I can do things like watch it draw the wfs features as they come in
(7:39:05 AM) jgarnett: indeed I do see this functionality
(7:39:37 AM) jgarnett: oh wait
(7:39:46 AM) jgarnett: you are saying it is rendering the non visible layers?
(7:39:58 AM) jgarnett: that would be a bug would it not?
(7:40:00 AM) emily_g: correct
(7:40:04 AM) emily_g: it renders all layers
(7:40:08 AM) emily_g: and only composes the visible ones
(7:40:08 AM) jgarnett: really
(7:40:14 AM) emily_g: I don't think its necessarily a bug
(7:40:18 AM) emily_g: just a design decision
(7:40:26 AM) jgarnett: is that a change we made on trunk? does 1.1.1 work that way?
(7:40:32 AM) jgarnett: I would think it is a bug
(7:40:32 AM) emily_g: it means that if you are always turning layers on and off they are ready for you and there is not delay
(7:40:40 AM) jgarnett: we do try not t othrow out an rendered image
(7:40:47 AM) jgarnett: when the user toggles a layer visibility on and off
(7:40:49 AM) emily_g: I don't know about 1.1.1; I can look
(7:41:06 AM) jgarnett: but if the user zooms or pans with a layer turned off
(7:41:18 AM) jgarnett: I do not expect that layer to start rendering again until they turn it on
(7:41:29 AM) jgarnett: so I guess it would be a bug that was introduced; and not noticed
(7:41:48 AM) emily_g: okay I'll look at 1.1.1
(7:41:52 AM) emily_g: and report to the mailing list
(7:43:06 AM) jgarnett: um question
(7:43:13 AM) jgarnett: can we "fix" this?
(7:43:18 AM) emily_g: :)
(7:43:23 AM) jgarnett: for an easy performance gain :-)
(7:43:31 AM) emily_g: yes I think it can be fixed
(7:43:35 AM) emily_g: I don't know how much work it would be
(7:43:42 AM) emily_g: and I don't know how much performance gain we would get
(7:43:59 AM) emily_g: that depends on how slow the layers are that you are rendering
(7:45:59 AM) emily_g: I don't think the hidden layer render is captured in the composition; i think it just runs int he background sucking up cpu cycles
(7:46:08 AM) jgarnett: to be clear: rendering layers that are not visisble was not the intended design here; so I support treating this as a bug
(7:46:19 AM) emily_g: okay
(7:46:37 AM) emily_g: I'll post a message to the list and see how complex it would be to change it
(7:49:29 AM) jgarnett: did you have another question?
(7:49:49 AM) jgarnett: how are things going on your end; you keep sending facinating posts about feature caching
(7:49:56 AM) jgarnett: but I have not looked at the code you are working on
(7:50:52 AM) jgarnett: jhudson has been hacking away at gdavis WMS-C work (and wants to hunt down a memory leak). I think he has asked Graham if he can contribute a few patches back
(7:51:32 AM) emily_g: fun
(7:51:43 AM) emily_g: my next question was about my caching
(7:52:06 AM) emily_g: it currently takes the features from the cache; combines them with features from the wfs and returns all these features in a memoryfeaturecollection
(7:52:11 AM) emily_g: this is bad for many reasons
(7:52:45 AM) emily_g: and I was thinking of looking at creating a featurecollection/feature iterator that would read the feature only when needed & not store them in memory
(7:52:52 AM) emily_g: am I crazy?
(7:53:41 AM) jgarnett: just a sec
(7:53:46 AM) jgarnett: it takes features from the cache
(7:53:52 AM) jgarnett: and combines them with feaures from the wfs
(7:54:06 AM) jgarnett: um so how is that a cache; if you are getting features from the wfs anyways?
(7:54:33 AM) emily_g: I'm only getting features I don't have in the cache
(7:54:33 AM) jgarnett: normally featurecollections/feature iterators only read the features when needed
(7:54:38 AM) jgarnett: ah okay
(7:54:58 AM) jgarnett: I am still having trouble with your last sentence; since what you describe is how the normal wfs datastore works
(7:55:23 AM) emily_g: right
(7:55:37 AM) emily_g: somehow I need to combine the features from the cache with the features from the wfs
(7:55:59 AM) emily_g: I am currently doing this by using a memory feature collection
(7:57:44 AM) jgarnett: I see
(7:57:51 AM) jgarnett: but you would like to do it "as needed"
(7:57:59 AM) emily_g: yes
(7:58:00 AM) jgarnett: ie when the user first calls an iterator over the collection
(7:58:02 AM) jgarnett: I tried this
(7:58:04 AM) jgarnett: and hurt my brain
(7:58:28 AM) jgarnett: because the user sometimes does not use that iterator over the whole collection (ie they can fetch the first item and then close it)
(7:58:39 AM) jgarnett: but It is a good approach
(7:59:04 AM) jgarnett: commons collections has a a LazySet that is cool
(7:59:09 AM) jgarnett: and actually works along these lines
(7:59:19 AM) jgarnett: it wraps over an iterator; and only populates itself as needed
(7:59:41 AM) emily_g: that's cool
(7:59:50 AM) emily_g: I'll have to have a look
(8:00:32 AM) emily_g: unfortunately the caching code is somewhat crazy so this will probably required something more complicated that this
(8:00:37 AM) emily_g: but at least it might be a good starting point
(8:00:39 AM) emily_g: thanks
(8:00:47 AM) pramsey_ [n=pramsey@S0106001ff3c5ddcb.gv.shawcable.net] entered the room.
(8:00:49 AM) emily_g: the caching stuff works great once the features are cached :P
(8:01:57 AM) jgarnett: that is good to know :-)
(8:02:05 AM) jgarnett: okay I am going to wrap up the logs; thanks for the chat
(8:02:18 AM) emily_g: cheers; have a great day!
(8:02:18 AM) jgarnett: and I really look forward to your feedback on the udig 1.2-M2 testing
(8:02:20 AM) emily_g: thanks for the help
(8:02:26 AM) jgarnett: (and hope it does not eat up my weekend)
(8:02:35 AM) emily_g: (it won't)
(8:03:17 AM) jgarnett: it is starting to get really beautiful here :-)
2 comments:
Post a Comment