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 <[email protected]> To: Tim Sutton <[email protected]> Cc: qgis-dev <[email protected]> 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 [email protected] 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. _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
