<div dir="ltr">Hey<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 12, 2013 at 5:50 PM, Martin Dobias <span dir="ltr"><<a href="mailto:wonder.sk@gmail.com" target="_blank">wonder.sk@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Tim!<br>
<div class="im"><br>
<br>
> That all sounds absolutely brilliant! Thanks for such a nice clear<br>
> description of how it all fits together. I know you are only considering<br>
> layer-by-layer rendering but does your design accommodate further future<br>
> optimisations easily? I'm thinking of things like:<br>
><br>
> * predictive / off screen rendering of 3x3 canvas dimensions after the<br>
> initial render so that any pan is near instantaneous (and would trigger a<br>
> new off-screen render)<br>
<br>
</div>I have had this idea in my mind while working on the project. In<br>
theory map canvas can spawn several renderer jobs (instead of just<br>
one) and let them render just one tile of the map. Some special<br>
handling of the labeling would be necessary if we wanted labels that<br>
are allowed to cross the border of tiles.<br>
<div class="im"><br></div></blockquote><div>Yeah - Larry and I had chatted before about using the AOI extents as a fake line feature with a 'may not be covered' rule in labelling - same for map viewframe when printing. I don't know if that is still on his agenda but it would be very nice to have.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> * on zoom, resample first then over render the resampled image (like open<br>
> layers and other web toolkits do so you see a resampled version of the old<br>
> render which gets overpainted as the new render comes in)<br>
<br>
</div>Actually that's already there :-)<br>
When you change the extent, the old map will be still present, just<br>
scaled. It will be there until the first update of the preview (now<br>
the default is set to 250ms). So, first quarter of the second you will<br>
be looking at the older resampled map (of course if your new map is<br>
rendered under 250ms, it will be shown as soon as it is done).<br>
<div class="im"><br></div></blockquote><div>Cool. And if you have the 3x3 AOI buffer you could resample the whole thing when zooming out and the user would have something quite pleasant to look at while waiting for a redraw.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> * symbol layer render in threads - I believe even single layer draws can<br>
> benefit greatly from the render-then-composite approach you are taking -<br>
> rendering each feature into a buffer when symbol layers are enabled (and<br>
> then compositing the buffers after rendering them) means that no feature<br>
> should need to be retrieved more than once when rendering.<br>
<br>
</div>This could be quite interesting thing to do. I guess the vector layer<br>
renderer class could actually spawn further rendering tasks for each<br>
symbol level after initial load of features and their division into<br>
groups based on their symbol.<br>
<div class="im"><br>
> * render caching of symbol layers (so that if only one layer gets changed<br>
> not all others need to be re-rendered)<br>
<br>
</div>So you mean render caching not only the whole map layers, but also<br>
levels within layers? I am not sure how big the benefit of introducing<br>
that would be - if the added code complexity wouldn't outweigh the<br>
benefit of optimizing such case (i.e. how much of user's total time in<br>
QGIS does he/she spend waiting for update after a change to a symbol<br>
layer?)<br>
<div class="im"><br></div></blockquote><div><br></div><div>Yeah this admittedly the weakest of the ideas I listed :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> * progressive rendering (e.g. rendering in a generalised way ala A Huarte's<br>
> patches and then update the display and the start a second pass render with<br>
> full detail) - that way you get a very fast first render but if you stick<br>
> around at that AOI the render quality improves as the second pass happens<br>
<br>
</div>I haven't really thought about that so far. We would probably need to<br>
employ some guessing to know when does it make sense to actually do<br>
the progressive rendering and when to render just once...<br>
<br>
This 'progressive' thing reminds me of another thing worth trying: by<br>
default we could try to cache all reasonably sized vector datasets<br>
upon their load into memory. Then we would render the layers without<br>
actually querying the backend. When the rendering is done, we could<br>
then optionally run the query on backend to check whether our cache<br>
needs updating.<br></blockquote><div><br></div><div>Yeah that would be awesome.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also, it may be interesting to build some temporary overviews for<br>
raster layers (if not present) and do the progressive rendering there<br>
- first a low quality render from the overview, then a real rendered<br>
image.<br>
<div class="im"><br>
<br></div></blockquote><div><br></div><div>Yeah that also sounds good!</div><div><br></div><div><br></div><div>Thanks again for making all this threading stuff happen!</div><div><br></div><div>Regards</div><div><br></div>
<div>Tim</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> I know there are possible issues with memory consumption with some of the<br>
> above ideas, and they are definitely not on your current roadmap, but it<br>
> would be good to at least play a little mental soccer with the above ideas<br>
> and see if the architecture you have devised can accommodate such further<br>
> optimisations cleanly in the future.<br>
<br>
</div>Sure, it is always good to think ahead about possible improvements!<br>
<br>
Cheers<br>
<span class="HOEnZb"><font color="#888888">Martin<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Tim Sutton - QGIS Project Steering Committee Member<br>==============================================<br>Please do not email me off-list with technical<br>
support questions. Using the lists will gain<br>more exposure for your issues and the knowledge<br>surrounding your issue will be shared with all.<br><br>Irc: timlinux on #qgis at <a href="http://freenode.net" target="_blank">freenode.net</a><br>
==============================================</div>
</div></div>