Hi, just tested with cache enabled and multi cpu .
Memory do not stop increasing on each new rendering, from 240 Mo starting
with no upper limit.
With cache disabled, I also face memory growth, but very slow, and probably
related to only some drawing actions (labels or raster? not sure).
Cheers,
Martin, maybe render caching should be turned/forced on by default on qgis
master builds right now so there can be a higher of ppl using it and
reporting possible regressions? If it's now smooth and problem-free
following mtr merge, it can be left on by default for final 2.4 release.
On 3 Mar 2014
Hi Paolo
On Mon, Mar 3, 2014 at 7:18 PM, Paolo Cavallini wrote:
> Il 27/02/2014 03:17, Martin Dobias ha scritto:
>
>> Paolo: make sure you have render caching turned on. Deactivating (and
>> activating again) a layer should be immediate. Of course, if you pan
>> the map or zoom in/out, everything
Il 27/02/2014 03:17, Martin Dobias ha scritto:
> Paolo: make sure you have render caching turned on. Deactivating (and
> activating again) a layer should be immediate. Of course, if you pan
> the map or zoom in/out, everything will be re-rendered.
Hi Martin,
thanks for this. It helps, but my ques
Hi Andreas
On Wed, Feb 26, 2014 at 9:48 PM, Andreas Neumann wrote:
>> Some of the slowness is understandable, some not really, e.g. why
>> deactivating a layer in the legend should require time?
>
> that's a case where the render-cache should work. When deactivating a
> layer, QGIS will just redr
Il 26/02/2014 17:25, Matthias Kuhn ha scritto:
> Fair enough to at least look at what's currently being done with the
> requested data and evaluating if it's appropriate (in every case) IMHO.
>
> That means, please open a ticket and add information about the executed
> queries if possible.
http:
On Wed 26 Feb 2014 05:09:53 PM CET, Paolo Cavallini wrote:
Il 26/02/2014 15:39, Sandro Santilli ha scritto:
I'd suggest to file a ticket for each case of that sort.
Thanks.
Would it be appropriate pointing out that deactivating a layer should
not load any data from the server? Seems reasonabl
Il 26/02/2014 15:39, Sandro Santilli ha scritto:
> I'd suggest to file a ticket for each case of that sort.
Thanks.
Would it be appropriate pointing out that deactivating a layer should
not load any data from the server? Seems reasonable to me.
All the best.
--
Paolo Cavallini - www.faunalia.eu
> Some of the slowness is understandable, some not really, e.g. why
> deactivating a layer in the legend should require time?
that's a case where the render-cache should work. When deactivating a
layer, QGIS will just redraw all remaining visible layers. In case the
render-cache was active it woul
On Wed, Feb 26, 2014 at 12:43:10PM +0100, Paolo Cavallini wrote:
> Il 26/02/2014 11:31, Matthias Kuhn ha scritto:
>
> >> Zooming and editing require loading of data (we don't cache much data
> >> locally)
>
> I see: wouldn't it be better to do it?
>
> >> * Activating server side simplification f
On Wed, Feb 26, 2014 at 02:52:28PM +0100, Paolo Cavallini wrote:
> Il 26/02/2014 13:29, Andreas Neumann ha scritto:
> > Hi,
> >
> > As far as I know libpq does not support compression.
> >
> > There is a lengthy discussion on libpq compression at
> > http://postgresql.1045698.n5.nabble.com/libpq-
It sounds like the PostGIS connection provider could use some optimisations.
The Oracle provider had/has a few which are being resolved (thanks
Jurgen!), but it does first require identifying what queries are being run
during what actions. If you have access, watch what queries are running on
Post
Il 26/02/2014 13:29, Andreas Neumann ha scritto:
> Hi,
>
> As far as I know libpq does not support compression.
>
> There is a lengthy discussion on libpq compression at
> http://postgresql.1045698.n5.nabble.com/libpq-compression-td5712541.html
Some of the slowness is understandable, some not re
Hi,
As far as I know libpq does not support compression.
There is a lengthy discussion on libpq compression at
http://postgresql.1045698.n5.nabble.com/libpq-compression-td5712541.html
Andreas
Am 26.02.2014 10:15, schrieb Paolo Cavallini:
> Hi all.
> Why exactly is using PostGIS so painful on a
Le 2014-02-26 11:30, Matthias Kuhn a écrit :
Solution (partly):
* Activating server side simplification for such layers gives a
noticeable speed boost here.
* Get a faster network ;)
What about requesting and using Tiny WKT when possible ? :)
http://osgeo-org.1560.x6.nabble.com/Use-of-Tiny-W
Il 26/02/2014 11:31, Matthias Kuhn ha scritto:
>> Zooming and editing require loading of data (we don't cache much data
>> locally)
I see: wouldn't it be better to do it?
>> * Activating server side simplification for such layers gives a
>> noticeable speed boost here.
just tried, I do no see a
On 02/26/2014 11:30 AM, Matthias Kuhn wrote:
Hi Paolo,
Explanation:
Zooming and editing require loading of data (we don't cache much data
locally)
Solution (partly):
* Activating server side simplification for such layers gives a
noticeable speed boost here.
* Get a faster network ;)
* I f
Hi Paolo,
Explanation:
Zooming and editing require loading of data (we don't cache much data
locally)
Solution (partly):
* Activating server side simplification for such layers gives a
noticeable speed boost here.
* Get a faster network ;)
Best
Matthias
On Wed 26 Feb 2014 11:15:22 AM CET,
Hi all.
Why exactly is using PostGIS so painful on a slow connection? I
understand that loading time is long, but I do not know why editing or
zooming should be so slow.
Any explanation? Better yet: any solution?
All the best.
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www
19 matches
Mail list logo