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
