Hi Jody, and thanks for the correction. I have re-posted it to udig-devel. Cheers, Kenneth
2011/7/12 Jody Garnett <[email protected]> > We should keep discussion on the email list; or on your bug report if > possible so others can take part. > > I would solve this for the specific WMS case 1st; and then ask Jesse for > review and see if the fix can be applied to other Renderers. > > While it is tempting to think that all of them could be fixed .... many of > the other renders do not completely replace all of their raster; and reply > on an empty buffered image to draw into. I can think of a couple of > workarounds; but I suspect that Jesse could shoot them down quickly ... on > the email list. > -- > Jody Garnett > > On Tuesday, 12 July 2011 at 9:38 PM, Kenneth Gulbrandsoy wrote: > > Hi Jesse! > > I've been told (by Jody) that you are the right person to ask questions > about the rendering sub-system in uDig :-) > > 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? > > Any tip, suggestions and comments are appreciated. > > Cheers, > kengu > > ---------- Forwarded message ---------- > From: *Kenneth Gulbrandsøy (JIRA)* <[email protected]> > Date: 2011/7/10 > Subject: [udig-devel] [jira] Created: (UDIG-1771) Improve the pan-redraw > rendering sub-system cycle > To: [email protected] > > > Improve the pan-redraw rendering sub-system cycle > ------------------------------------------------- > > Key: UDIG-1771 > URL: https://jira.codehaus.org/browse/UDIG-1771 > Project: uDIG > Issue Type: Improvement > Components: visualization using map layer and style > Affects Versions: UDIG 1.2.2 > Environment: Ubuntu 10.04 LTS 64bit, JRE 1.6, Eclipse 3.6.1 > Reporter: Kenneth Gulbrandsøy > Priority: Minor > Fix For: UDIG 1.2.x > Attachments: test-0000.mpeg, test-0001.mpeg, test-0002.mpeg, > test-0003.mpeg, test-0004.mpeg, test-0005.mpeg > > When panning a map with a WMS layer as a "background map", the WMS layer > disappear (is cleared), from the moment that the mouse button is released, > until the new WMS image is received. This is a bit annoying, reducing the > overall user experience. It would be better if the rendering sub-system kept > all old caches as they were on mouse button release, only clearing the map > extents which require new data. > > After some initial debugging of the rendering sub-system, it seems that > other renderers suffers from the same problem (shape and postgis tested so > far). But since these renders receives new data much faster then WMS, the > "white-out" phase is much shorter, and therefore appear to keep the panned > map until new data is received, just as described above. > > My understanding of the rendering sub-system is not that good (it is hard > to debug), but it seems to me that there is a "white-out" gap between the > request for new map bounds and the actual rendering of it. My experiments > show that this gap increase with the latency metric (see video screen > captures). Since WMS has a significantly longer latency then f.ex. postgis, > the problem become more visible when using a WMS georesource as a background > map. > > I have attached six screen capture videos showing the problem for WMS, > Shape and PostGIS (one without break-points and another with break-points > per georesource). These show that all renderers clear the map before new > data is received, which underpin my conclusions. > > If somebody with a better understanding of the sub-system than me can shed > some light on the reasons behind the "white-out" phase, and where this > happens in the redraw cycle, I would be happy to look into solutions that > remove the gap. > > -- > This message is automatically generated by JIRA. > For more information on JIRA, see: http://www.atlassian.com/software/jira > > > _______________________________________________ > User-friendly Desktop Internet GIS (uDig) > http://udig.refractions.net > http://lists.refractions.net/mailman/listinfo/udig-devel > > >
_______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
