Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [udig-devel] [jira] Created: (UDIG-1771) Improve the pan-redraw rendering sub-system cycle

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 <jesse.eichar@xxxxxxxxxxxxxx>
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 <kenneth.gulbrandsoy@xxxxxxxxx> 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 <jesse.eichar@xxxxxxxxxxxxxx>
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 <kenneth.gulbrandsoy@xxxxxxxxx> wrote:
Comments in line.

2011/7/13 Jesse Eichar <jesse.eichar@xxxxxxxxxxxxxx>
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, 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 






Back to the top