Feature request #1974
Enable render caching where possible
Status: | Closed | ||
---|---|---|---|
Priority: | Low | ||
Assignee: | Tim Sutton | ||
Category: | Map Canvas | ||
Pull Request or Patch supplied: | Resolution: | fixed | |
Easy fix?: | No | Copied to github as #: | 12034 |
Description
User story 1:
Joe is reordering layers, each of which points back to a postgis database with thousands of records. Each time he drops a layer to a new position, he waits a long time while each layer redraws, even though the content of the layers is the same, just being rendered in a different order.
User story 2:
Jane is changing symbology in a layer. When she clicks apply, she waits a long time while all other layers redraw too.
User story 3:
Pete is hiding and showing layers. Each time he hides or shows a layer, he waits a long time while the layers redraw.
The solution to this is to provide some kind of caching mechanism. The attached patch is my first draft that addresses the above scenarios and makes QGIS much more responsive when engaged in the activities described.
Please note the patch is a work in progress and there are some edge cases where it does not yet behave well. In order to activate caching, tick the checkbox for this in the rendering tab of the options panel (its disabled by default).
History
#1 Updated by Tim Sutton about 15 years ago
Version 5 offers dramatically better performance now that I have changed it to use QImage rather than QPixmap. The last remaining task is to clear the cache images of non-visible layers when the extents change to prevent rendering anomalies when enabling display of a layer after a zoom operation.
#2 Updated by Tim Sutton about 15 years ago
- Status changed from Open to In Progress
#3 Updated by Tim Sutton about 15 years ago
Version 6 of the patch is now quite usable and deals well with most issues I think. I will propose this patch for inclusion into trunk.
#4 Updated by Tim Sutton about 15 years ago
- Resolution set to fixed
- Status changed from In Progress to Closed
This patch is applied to trunk as of 763fbb20 (SVN r11832).