Feature request #2037
Enable multi-threaded rendering in QGIS
|Assigned to:||-||% Done:||
|Target version:||Future Release - Nice to have|
|Platform version:||Pull Request or Patch supplied:||No|
User story 1: Joe has a multicore processor but when QGIS is rendering a map, one of the cores is heavily utilised whilst the rest remain idle.
User story 2: Pam wishes she didnt need to wait so long for maps to draw as each layer draw carries out a long running query against a database backend.
Qt4 includes QThread which makes writing multithreaded cross platform libraries fairly easily. Thus it would be good to start thinking about how we can make QGIS take advantage of this.
In my mind there are two main areas of work required:
- making map layers inherit from QThread and adding in sufficient foundation for them to be able to render in a thread (pretty much covered in the attached patch).
- Updating qgsmaprenderer.cpp to orchestrate the threaded rendering of map layers and the composition of the results.
For the second (renderer part) we will need to split the render process into three parts I think:
- a setup phase which sets the render context for each maplayer (which would need to become a member of qgsmaplayer) and then calls the run() method to launch the thread
- a slot to listen for when each thread is done and tally up when all the rendering work is completed
- a finalise method to end the render process with label and acetate rendering and perform final compositing from layer render cache images.
|related to QGIS Application - Bug report #8889: Slow "selection" of features||Closed||10/17/2013|
Updated by Marco Hugentobler over 7 years ago
Please also consider the QtConcurrent (http://doc.trolltech.com/4.5/threads.html#qtconcurrent) framework as an option. The advantage over inheritance from QThread is that the number of created threads automatically adapts depending on the number of cores. Furthermore it is more high-level and therefore simpler to use. And it does not require api changes in QgsMapLayer.
Updated by Martin Dobias over 7 years ago
I'd like to second Marco's suggestion. Inheriting map layers from QThread looks like a bad design decision...
Updated by Paolo Cavallini almost 7 years ago
There is an ongoing Summer of Code project dealing with this. Hopefully we'll see the results in a couple of months
Updated by Aren Cambre over 5 years ago
- Assigned to deleted (
- Platform deleted (
- Pull Request or Patch supplied set to No
Has anything come of this?
Updated by Giovanni Manghi over 5 years ago
- Target version changed from Version 1.7.0 to Version 1.7.4
Updated by Nathan Woodrow about 5 years ago
- Target version changed from Version 1.7.4 to Version 2.0.0
No. I would say that last update was a mistake.
2.0 would be the best target as I haven't seen much work on this in a while.
Updated by Aren Cambre about 5 years ago
OK, thanks. This would be an exciting improvement. Is "low" priority really correct?
Updated by Pirmin Kalberer over 4 years ago
- Target version changed from Version 2.0.0 to Future Release - Nice to have
Updated by Aren Cambre over 3 years ago
I'm surprised this remains low priority. This would be a huge benefit for complex maps.
Updated by Nathan Woodrow over 3 years ago
It's not really low as Martin is planning to work on it after 2.0.
Also available in: Atom