[Qgis-developer] [Qgis-user] WMS Rendering Problems

[Marco Hugentobler]

Hi Jürgen and Tim,

I would also prefer that code for asynchronous requests is as invisible as 
possible.

WFS provider already uses asynchronous requests for quite a while, using 
direclty QHttp, not QgsHttpTransaction (see code in 
src/providers/wfs/qgswfsdata.cpp/h).

I changed the postgis provider in svn a few weeks ago to make asynchronous 
requests. It now uses the asynchronous call 'PQsendQuery' that is provided by  
libpq. That means while the database server collects and sends the next 200 
features, QGIS already draws the ones from the last request. I only tested 
with one remote database, and the performance effect was quite large. For 
local databases, performance gain is not very large.

For these two providers, the asynchronous requests are completely handled 
inside the provider code (which makes it quite invisible for the rest of the 
code). 

A benefit of a higher level code could be that requests to several WMS servers 
can be released one after each other and once everything is there, the images 
are drawn in the correct order. This makes operations with several servers 
very fast and is not possible with the solution on provider level.

Regards,
Marco  
 

On Thursday 01 November 2007 09:46:55 Tim Sutton wrote:
> Hi
>
> 2007/11/1, Jürgen E. Fischer <jef at norbit.de>:
> > Hi Tim,
> >
> > On Wed, 31. Oct 2007 at 22:55:39 -0300, Tim Sutton wrote:
> > > Was anyone able to test Toms patch? Can we go ahead and apply it to
> > > trunk? We would like to do a follow up release of QGIS 0.9.1 in the
> > > next few days - in particular to provide updated binaries to address
> > > some GRASS issues Martin fixed, and to provide a Toms WMS fix.
> >
> > I tested.  The attached path includes a few more changes that made it
> > work for me (notably the handling of redirections in
> > QgsHttpTransaction).
>
> Great!
>
> > Have you looked at the patch?  We probably don't want the upper layers
> > to know about WMS and need a more generic way to handle data providers
> > asynchronously.
>
> I had a look at Toms patch. From what I can see the main upper level
> API that does this is here:
>
> @@ -617,7 +657,24 @@
>
>  void QgsMapRender::setLayerSet(const QStringList& layers)
>  {
> +  QgsMapLayerRegistry* registry = QgsMapLayerRegistry::instance();
> +  QStringList::iterator it = mLayerSet.begin();
> +  while (it != mLayerSet.end())
> +  {
> +    QgsRasterLayer *rl = dynamic_cast<QgsRasterLayer
> *>(registry->mapLayer(*it));
> +    if (rl && rl->providerKey() == "wms")
> +      disconnect(rl, SIGNAL(imageAvailable()), this,
> SLOT(asyncLayerDone())); +    ++it;
> +  }
>    mLayerSet = layers;
> +  it = mLayerSet.begin();
> +  while (it != mLayerSet.end())
> +  {
> +    QgsRasterLayer *rl = dynamic_cast<QgsRasterLayer
> *>(registry->mapLayer(*it));
> +    if (rl && rl->providerKey() == "wms")
> +      connect(rl, SIGNAL(imageAvailable()), this, SLOT(asyncLayerDone()));
> +    ++it;
> +  }
>    updateFullExtent();
>  }
>
> The other parts dont look problematic to me. So basically we just need
> to figure out a way to move that logic down the stack somehow. I do
> wonder if the imageAvailable() could not be implemented rather as a
> more generic QgsMapLayer::dataAvailable() - I can envisage a situation
> where this same functionality could be useful for WFS or indeed for
> renderers that spawn a separate thread in the future (might be nice
> e.g. in postgres/postgis to fetch large queries back for example).
>
> Regards
>
> Tim
>
> > Jürgen
> >
> > --
> > Jürgen E. Fischer         norBIT GmbH               Tel.
> > +49-4931-918175-0 Dipl.-Inf. (FH)           Rheinstraße 13           
> > Fax. +49-4931-918175-50 Software Engineer         D-26506 Norden         
> >      http://www.norbit.de
> >
> > --
> > norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
> > Rheinstrasse 13, 26506 Norden
> > GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502



-- 
Dr. Marco Hugentobler
Institute of Cartography
ETH Zurich
Technical Advisor QGIS Project Steering Committee
marco.hugentobler at karto.baug.ethz.ch