Bug report #22132
Slow Vector Layer Line Rendering Speed
| Status: | Feedback | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: | - | ||
| Category: | Vectors | ||
| Affected QGIS version: | 3.6.3 | Regression?: | No |
| Operating System: | Windows 10 | Easy fix?: | No |
| Pull Request or Patch supplied: | No | Resolution: | |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 29943 |
Description
I've had layer rendering speed issues since going from 3.2 to 3.4 which continued on up to 3.6.3. The GPS traces in an 820 MB spatialite database take many times as long to draw as they used to.
Today I stumbled across a workaround for it by accident. When I reduced the line width from the default to 0.03 in order to render a high resolution png, the old performance level was restored. I could increase the line width to 0.13 without a performance hit, but 0.14 or higher and back to molasses.
I'm unsure if there is something special in general about the transition between line thickness at those numbers, or if it maybe be the thickness in my data at which the many parallel lines become wide enough to start overlapping.
History
#1
Updated by Giovanni Manghi over 5 years ago
- Affected QGIS version changed from 3.4.0 to 3.6.3
- Status changed from Open to Feedback
Can you add a link to a dataset we can use to replicate this issue?
#2
Updated by David MacNeil over 5 years ago
Zipped Spatialite database: https://drive.google.com/open?id=1dp4SEm-qmLzrs335j4MEaRTXriPpeR3I The table I'm using is called tracklines.
#3
Updated by Giovanni Manghi over 5 years ago
David MacNeil wrote:
Zipped Spatialite database: https://drive.google.com/open?id=1dp4SEm-qmLzrs335j4MEaRTXriPpeR3I The table I'm using is called tracklines.
just tried here on Linux and no issues whatsoever regardless the size/type of symbology.
#4
Updated by David MacNeil over 5 years ago
One thing I should add is that the slowdown is much more pronounced on a UHD monitor compared to my 1080p secondary monitor. But even on the 1080p monitor redraw is noticeably slower with a thicker line width.
Since you were unable to replicate on Linux it may be a Windows or Windows 10 specific issue.
#5
Updated by Giovanni Manghi over 5 years ago
David MacNeil wrote:
One thing I should add is that the slowdown is much more pronounced on a UHD monitor compared to my 1080p secondary monitor. But even on the 1080p monitor redraw is noticeably slower with a thicker line width.
Since you were unable to replicate on Linux it may be a Windows or Windows 10 specific issue.
all ok on Windows too, here.