<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>What is this "preview job" function?</p>
<br>
<div class="moz-cite-prefix">On 16/11/17 03:56, Even Rouault wrote:<br>
</div>
<blockquote type="cite" cite="mid:8444006.lOr4mHJqye@even-i700">
<meta name="qrichtext" content="1">
<style type="text/css">
p, li { white-space: pre-wrap; }
</style>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Hi,</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; "> </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">I'm working currently on improving raster performance per</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><a class="moz-txt-link-freetext" href="https://github.com/qgis/QGIS/pull/5632">https://github.com/qgis/QGIS/pull/5632</a> , 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)</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; "> </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Wouldn't it make sense to offer an option to disable preview jobs on the main canvas for such use case ?</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">I guess this could also be useful for complex projects with many layers of "fast datasources", but where the global rendering time is large.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; "> </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">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.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; "> </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">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)</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">
</p>
</blockquote>
<br>
</body>
</html>