1. uDIG
  2. UDIG-1771

Improve the pan-redraw rendering sub-system cycle


    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: UDIG 1.2.2
    • Fix Version/s: 2.x
    • Labels:
    • Environment:
      Ubuntu 10.04 LTS 64bit, JRE 1.6, Eclipse 3.6.1


      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.

      1. test-0000.mpeg
        666 kB
        Kenneth Gulbrands°y
      2. test-0001.mpeg
        1.21 MB
        Kenneth Gulbrands°y
      3. test-0002.mpeg
        385 kB
        Kenneth Gulbrands°y
      4. test-0003.mpeg
        627 kB
        Kenneth Gulbrands°y
      5. test-0004.mpeg
        329 kB
        Kenneth Gulbrands°y
      6. test-0005.mpeg
        671 kB
        Kenneth Gulbrands°y


        JoaquÝn RodrÝguez-Guerra added a comment -
        I totally agree on this, it would be a great improvement in the user experience
        JoaquÝn RodrÝguez-Guerra added a comment - I totally agree on this, it would be a great improvement in the user experience


          • Assignee:
            Kenneth Gulbrands°y


            • Created: