I think so, but we will know when I have written an RFC explaining what I plan to do. I think that is a good practice, because it gives me the opportunity to have some feedback on design before I start hacking away.
I'm also working on another RFC on uDig database persistence (framework for persistence of EMF models in uDig), I hope I'm able to write up both before the my vacation starts. Cheers, Kenneth 2011/7/14 Jesse Eichar <[email protected]> > group layer definitely has big value. I look forward to that work as well. > So you have enough information to continue? > > > On Wed, Jul 13, 2011 at 2:34 PM, Kenneth Gulbrandsoy < > [email protected]> wrote: > >> Fair enough, although the group layer approach is something that I will >> pursue in near future (mid-autumn probably) as part of another project :-) >> >> Cheers, >> Kenneth >> >> 2011/7/13 Jesse Eichar <[email protected]> >> >>> I wonder if the baselayer solution is really worthwhile because one would >>> need to add a new concept into the UI somehow. For example in the addLayers >>> dialog or something. Likely it would also have to be added to layers view >>> and possibly force the layers to always be unmoveable. >>> >>> It is possible that you could for now simply use all the WMS layers as a >>> baselayer and we can see about something more sophisticated another time. >>> >>> Jesse >>> >>> >>> On Wed, Jul 13, 2011 at 10:55 AM, Kenneth Gulbrandsoy < >>> [email protected]> wrote: >>> >>>> Comments in line. >>>> >>>> 2011/7/13 Jesse Eichar <[email protected]> >>>> >>>>> Comments in line: >>>>> >>>>> The problem I'm trying to solve is described here: >>>>> https://jira.codehaus.org/browse/UDIG-1771 >>>>> >>>>>> >>>>>> After some initial and follow-up IRC chats with Jody, I'm ready to do >>>>>> some experimentation with the basic WMS renderer plug-in. So far, I have >>>>>> copied the basic WMS rendered into a experimental WMS renderer plug-in. >>>>>> I haven't done a "git push" to my clone >>>>>> yet<http://github.org/kengu/udig-platform>, >>>>>> but I plan to do so shortly. >>>>>> >>>>>> I The following changes to the basic Renderer (a mix-up of IRC chats >>>>>> with Jody) is believed to solve the flikkering problem: >>>>>> >>>>>> 1) Detect map extent changed BEFORE buffered image in RendererContext >>>>>> is cleared >>>>>> 2) Cache current buffered image >>>>>> 3) Clear image to background color >>>>>> 4) If current and new extent overlap, draw clip to buffered image (if >>>>>> disjoint, do the same as today) >>>>>> 5) Use this clipped image until new data has been received from >>>>>> georesource (stretching and compressing it to given zoom levels) >>>>>> >>>>> >>>>>> So, my questions are: >>>>>> >>>>>> 1) Does it suffice to implement this in the Renderer only, or do you >>>>>> think that the RendererContext must be changed also? >>>>>> 2) Do you agree with my conclusion that the unwanted behavior exists >>>>>> for all renderers, although WMS suffers the most because of the latency? >>>>>> >>>>>> >>>>> I have a couple ideas. >>>>> >>>>> 1 it could be done in the renderer but if that is the case then you >>>>> will blow up the already large memory requirements of uDig. Consider 10 >>>>> WMS >>>>> layers. If the user re-orders then serveral times and inserts some vector >>>>> layers it is possible to end up with 10 WMS Renderers. Each would have 2 >>>>> buffered images the size of the display area. That would be very memory >>>>> intensive as you can imagine. >>>>> >>>> >>>> Good point, this will become big problem for sure. >>>> >>>> >>>>> >>>>> Another idea would be to keep all layers as the background and draw >>>>> overtop as the data comes in, then delete it when rendering is finished. >>>>> >>>>> Yet another idea would be to mark layers as base layers and keep their >>>>> composite rendering in the background until they are finished. >>>>> >>>> With the eventing it is possible to detect when a particular renderer is >>>>> finished so this is an option as well. >>>>> >>>> >>>> I prefer this option. The notion of base layers is pretty general, and >>>> has been mentioned several time on the list already I believe. >>>> >>>> >>>>> It is probably the most visually appealing but from a usability POV it >>>>> is difficult because how are they baselayers determined? >>>>> >>>> >>>> So what about introducing it as new layer type? This also aligns nicely >>>> with the concept of a group layer which which logically groups layers into >>>> one single layer. This allows us to add a caching strategy where the group >>>> layer caches current image on behalf of the layers it groups. I'm up to the >>>> challenge, but it would be really nice to work with someone that knows >>>> the rendering sub-system in detail. I can do the dirty work, but I really >>>> need someone to guide me through the process :-) >>>> >>>> >>>>> >>>>> Jesse >>>>> >>>> >>>> Kenneth >>>> >>>> >>> >> >
_______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
