[QGIS-Developer] Incremental drawing possible?

[Neumann, Andreas]

Hi Martin, 

Sounds interesting. Of course this is not urgent. We now need to
concentrate on all the stuff that requires refactoring and API changes
in the master branch. 

But it would really be nice, if such rendering improvements could be
introduced in a future 3.x version. Maybe something for the next QGIS
grants program? 

Andreas 

On 2017-07-11 10:48, Martin Dobias wrote:

> Hi Andreas
> 
> On Tue, Jul 11, 2017 at 9:38 AM, Neumann, Andreas <a.neumann at carto.net> wrote: 
> 
>> Hi Martin,
>> 
>> I noticed that loading and redraw only happens when the mouse button is
>> released after the panning operation. While I understand the reasoning for
>> this (definitely on the safe side and no unnecessary redraws), I wonder, if
>> for WMTS, loading and display could already happen while panning and the
>> mouse button isn't yet released, e.g. triggered whenever a certain threshold
>> of panning distance (e.g. in percent of the last extent) was surpassed.
>> 
>> This would be even nicer than the current behaviour. Or are there technical
>> reasons, not to do that? Google maps works like this. It redraws while
>> panning.
> 
> Good news - there are no technical reasons that would prohibit us from
> such improvement. Background rendering could start earlier, we just
> need to add logic for such behavior. There is already a pending pull
> request from Nyall to render adjacent parts of map canvas once
> rendering of the visible area has finished - that may already be a
> sufficient solution - I have not had time to play with it yet though.
> Maybe these two approaches (render on map dragging, render outside of
> current view) can be combined somehow for the best UX while keeping
> overhead of extra rendering low.
> 
> We could even think about moving more towards tile-based approach to
> rendering of map canvas, with the advantage of being able to cache map
> tiles from previous canvas redraws for the same scale. This would
> allow instant appearance of areas previously rendered with lower CPU
> use at the expense of consuming more memory and having more
> complicated logic for labeling.
> 
> Regards
> Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20170711/2d8c2116/attachment-0001.html>