[QGIS-Developer] Incremental drawing possible?

Neumann, Andreas a.neumann at carto.net
Tue Jul 11 02:54:56 PDT 2017


Nice - I will test that branch. 

Andreas 

On 2017-07-11 11:26, Nyall Dawson wrote:

> On 11 July 2017 at 19:22, Neumann, Andreas <a.neumann at carto.net> wrote: 
> 
>> 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 - do you compile master builds? I'd love it if you could give
> the branch from https://github.com/qgis/QGIS/pull/4777 a test and give
> feedback on the open questions in that PR. I suspect you'll be pleased
> with the behavior with that change.
> 
> Full credit for the changes goes to Sourcepole - I've just forward
> ported the feature from their fork and modernised the code for 3.0.
> 
> Nyall
> 
>> 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/4030dd12/attachment.html>


More information about the QGIS-Developer mailing list