Thursday, January 29, 2009

IRC Logs January 30th

Agenda:

1) udig 1.2-M2 testing

2) rendering of invisible layers

3) feature cache implementation approach

(7:24:37 AM) jgarnett: this is the right time slot for an IRC meeting(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 :-)