[QGIS-Developer] Preview job and slow datasources

Nyall Dawson nyall.dawson at gmail.com
Wed Nov 15 13:01:56 PST 2017


On 16 November 2017 at 00:56, Even Rouault <even.rouault at spatialys.com> wrote:
> Wouldn't it make sense to offer an option to disable preview jobs on the
> main canvas for such use case ?

I agree with Matthias here, in that we want to avoid adding a
user-configurable option for this. Either we can get the preview jobs
tamed and stable enough to always enable, or we ifdef them out and
leave them to a future release.

> 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.

I like it!

> 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).

I think both approaches could be done to ease the burden of these
jobs. I'm thinking that possibly there's cases were individual layer
renders take < 250ms, but all together the total render time still
exceeds the 250ms timeout (e.g. due to large number of layers being
rendered). In this case we should still avoid having multiple preview
jobs being rendered at once.

On that note, in Nodebo Martin suggested that if we had a limit of one
preview job at a time we could intelligently prioritise these too.
E.g. the first job is the done in the same direction as the last
canvas move (assuming the next move will be in the same direction - "i
didn't move far enough"), then the opposite direction ("oops, went too
far"), and then the rest of the jobs...

Nyall


More information about the QGIS-Developer mailing list