[QGIS-Developer] Preview job and slow datasources

Matthias Kuhn matthias at opengis.ch
Wed Nov 15 07:18:29 PST 2017


Hi Even,

we have shortly discussed this topic in the past and the general
consensus was, not to offer such an option (which is easy to forget and
hard to set right without deep knowledge).

Should we consider a `virtual QgsDataProvider::renderInPreview()`
method, that can be finetuned by each provider and has a default
implementation that either uses rendering times as heuristics or just
blacklists some known-expensive types?

Matthias

On 11/15/2017 03:56 PM, Even Rouault wrote:
> Hi,
> 
>  
> 
> I'm working currently on improving raster performance per
> 
> https://github.com/qgis/QGIS/pull/5632 , and while testing with a
> variety of GDAL datasources, I found that the "preview job" (*)
> mechanism that is currently enabled on the main canvas (pre-rendering
> the 8 zones around the canvas extent) can have adverse performance
> impact with very slow datasources. Particularly those doing network
> accesses, where the bandwidth consumed by the preview jobs prevents the
> main rendering job to being served first (due to the fact the the
> preview jobs of the previous interaction are not immediately cancelled
> by the next one since, because being busy in libcurl calls)
> 
>  
> 
> Wouldn't it make sense to offer an option to disable preview jobs on the
> main canvas for such use case ?
> 
> I guess this could also be useful for complex projects with many layers
> of "fast datasources", but where the global rendering time is large.
> 
>  
> 
> A clever variant would measure the execution time of those preview jobs,
> and if, for example, it is above the 250 ms delay in which they are
> fired by QgsMapCanvas::schedulePreviewJob(), it would automatically
> disable it (potentially, temporarily, until the number of layers
> changes). In the case I mentionned above, each preview job takes several
> seconds to complete.
> 
>  
> 
> Or a simpler alternative would be to schedule the next preview job after
> the previous preview job has completed (instead of starting them every
> 250 ms). This would not be completely ideal with my above mentionned
> network case, compared to completely disabling preview jobs, but that
> could be a reasonable compromise, and would limit the CPU load of
> preview jobs to at most one core (currently if the preview jobs run
> slowly, they can "eat" up to 8 cores, since they are 8 preview jobs)
> 
>  
> 
> Thoughts ?
> 
>  
> 
> Even
> 
>  
> 
> (*) added per
> 
> https://github.com/qgis/qgis/commit/2d531e5814c1b43a23c36d09ace9a5f5729e5bb4
> 
>  
> 
> -- 
> 
> Spatialys - Geospatial professional services
> 
> http://www.spatialys.com
> 
> 
> 
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> 


More information about the QGIS-Developer mailing list