[Qgis-developer] QGIS Multi-threaded Rendering

[Saber Razmjooei]

And here is a video showing the difference for rendering only:
http://www.lutraconsulting.co.uk/casestudies/qgis-multi-threaded-rendering

Regards,
Saber


-----Original Message-----
From: Martin Dobias <wonder.sk at gmail.com>
To: Tim Sutton <lists at linfiniti.com>
Cc: qgis-dev <qgis-developer at lists.osgeo.org>
Subject: Re: [Qgis-developer] QGIS Multi-threaded Rendering
Date: Thu, 12 Dec 2013 22:50:44 +0700

Hi Tim!


> That all sounds absolutely brilliant! Thanks for such a nice clear
> description of how it all fits together. I know you are only considering
> layer-by-layer rendering but does your design accommodate further future
> optimisations easily? I'm thinking of things like:
>
> * predictive / off screen  rendering of 3x3 canvas dimensions after the
> initial render so that any pan is near instantaneous (and would trigger a
> new off-screen render)

I have had this idea in my mind while working on the project. In
theory map canvas can spawn several renderer jobs (instead of just
one) and let them render just one tile of the map. Some special
handling of the labeling would be necessary if we wanted labels that
are allowed to cross the border of tiles.

> * on zoom, resample first then over render the resampled image (like open
> layers and other web toolkits do so you see a resampled version of the old
> render which gets overpainted as the new render comes in)

Actually that's already there :-)
When you change the extent, the old map will be still present, just
scaled. It will be there until the first update of the preview (now
the default is set to 250ms). So, first quarter of the second you will
be looking at the older resampled map (of course if your new map is
rendered under 250ms, it will be shown as soon as it is done).

> * symbol layer render in threads - I believe even single layer draws can
> benefit greatly from the render-then-composite approach you are taking -
> rendering each feature into a buffer when symbol layers are enabled (and
> then compositing the buffers after rendering them) means that no feature
> should need to be retrieved more than once when rendering.

This could be quite interesting thing to do. I guess the vector layer
renderer class could actually spawn further rendering tasks for each
symbol level after initial load of features and their division into
groups based on their symbol.

> * render caching of symbol layers (so that if only one layer gets changed
> not all others need to be re-rendered)

So you mean render caching not only the whole map layers, but also
levels within layers? I am not sure how big the benefit of introducing
that would be - if the added code complexity wouldn't outweigh the
benefit of optimizing such case (i.e. how much of user's total time in
QGIS does he/she spend waiting for update after a change to a symbol
layer?)

> * progressive rendering (e.g. rendering in a generalised way ala A Huarte's
> patches and then update the display and the start a second pass render with
> full detail) - that way you get a very fast first render but if you stick
> around at that AOI the render quality improves as the second pass happens

I haven't really thought about that so far. We would probably need to
employ some guessing to know when does it make sense to actually do
the progressive rendering and when to render just once...

This 'progressive' thing reminds me of another thing worth trying: by
default we could try to cache all reasonably sized vector datasets
upon their load into memory. Then we would render the layers without
actually querying the backend. When the rendering is done, we could
then optionally run the query on backend to check whether our cache
needs updating.

Also, it may be interesting to build some temporary overviews for
raster layers (if not present) and do the progressive rendering there
- first a low quality render from the overview, then a real rendered
image.


> I know there are possible issues with memory consumption with some of the
> above ideas,  and they are definitely not on your current roadmap, but it
> would be good to at least play a little mental soccer with the above ideas
> and see if the architecture you have devised can accommodate such further
> optimisations cleanly in the future.

Sure, it is always good to think ahead about possible improvements!

Cheers
Martin
_______________________________________________
Qgis-developer mailing list
Qgis-developer at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


--
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately 
by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified 
that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

Whilst reasonable care has been taken to avoid virus transmission, no responsibility for viruses is taken and it is your responsibility to carry out 
such checks as you feel appropriate.

Saber Razmjooei and Peter Wells trading as Lutra Consulting.