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

[Tim Sutton]

Hi

Agreed, what you say makes good sense to me...

Some time ago I also mentioned implementing a composition engine. It
seems to me if QgsMapLayer inherited qthread, and layers emitted two
signals:

renderUpdated(QPixmap)    (or whatever appropriate paint device)
renderCompleted(QPixmap)

we could just start each layer rendering in its own thread and long
running operations could happen concurrently. Then the composition
manager can just update its cached copy of each layer being rendered
as it receives those signals, and then trigger a canvas repaint as
needed. It would seem to me we would get a good performance boost
assuming we dont run into issues e.g. spawning 1000's of threads if
the user has 1000's of layers loaded. Anyway now I am probably
wondering far off topic into feature dreamland again...

Regards

Tim

Regards

Tim

2007/11/1, Marco Hugentobler <marco.hugentobler at karto.baug.ethz.ch>:
> 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
>


-- 
Tim Sutton
QGIS Project Steering Committee Member - Release  Manager
Visit http://qgis.org for a great open source GIS
openModeller Desktop Developer
Visit http://openModeller.sf.net for a great open source ecological
niche modelling tool
Home Page: http://tim.linfiniti.com
Skype: timlinux
Irc: timlinux on #qgis at freenode.net