Re: [QGIS-Developer] Preview job and slow datasources

[Patrick Dunford]

In my current project using Qgis 2.99, turning off the rasters uses 16 
GB, turning them on uses 52 GB


I do not believe it is independent from the number of layers that are 
being displayed.


Previous versions of the software did not cache every single raster (the 
number of rasters actually being displayed on the canvas at any one time 
is a small fraction of the total number in the project)


On 16/11/17 20:11, Matthias Kuhn wrote:


Hi Patrick,

This uses some memory (~ canvas width pixels * canvas height pixels * 
8 preview images * 32 bit RGBA), so let's assume 50 MB to 100 MB.


This consumption is independent from the number or type of layers.

Matthias


On 11/16/2017 08:02 AM, Patrick Dunford wrote:


So to put it another way this is the reason why Qgis wants to use a 
huge amount of memory (40 GB) when I have a lot of raster images 
loaded in the background.



On 16/11/17 18:56, Tim Sutton wrote:

Hi

On 16 Nov 2017, at 04:35, Patrick Dunford > wrote:


What is this "preview job" function?




Its application logic to prefetch / pre-render offscreen content in 
anticipation of user panning the map.


Regards

Tim


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org 
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


—






*Tim Sutton*

*Co-founder:*Kartoza
*Project chair:*QGIS.org 

Visit http://kartoza.com  to find out about 
open source:


Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

*Skype*: timlinux
*IRC:*timlinux on #qgis at freenode.net 





___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info:https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe:https://lists.osgeo.org/mailman/listinfo/qgis-developer




___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Preview job and slow datasources

[Matthias Kuhn]

Hi Patrick,

This uses some memory (~ canvas width pixels * canvas height pixels * 8
preview images * 32 bit RGBA), so let's assume 50 MB to 100 MB.

This consumption is independent from the number or type of layers.

Matthias


On 11/16/2017 08:02 AM, Patrick Dunford wrote:
>
> So to put it another way this is the reason why Qgis wants to use a
> huge amount of memory (40 GB) when I have a lot of raster images
> loaded in the background.
>
>
> On 16/11/17 18:56, Tim Sutton wrote:
>> Hi
>>
>>> On 16 Nov 2017, at 04:35, Patrick Dunford >> > wrote:
>>>
>>> What is this "preview job" function?
>>>
>>>
>>
>> Its application logic to prefetch / pre-render offscreen content in
>> anticipation of user panning the map.
>>
>> Regards
>>
>> Tim
>>>
>>> ___
>>> QGIS-Developer mailing list
>>> QGIS-Developer@lists.osgeo.org 
>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>> —
>>
>>
>>
>>
>>
>>
>> *Tim Sutton*
>>
>> *Co-founder:* Kartoza
>> *Project chair:* QGIS.org 
>>
>> Visit http://kartoza.com  to find out about open
>> source:
>>
>> Desktop GIS programming services
>> Geospatial web development
>> GIS Training
>> Consulting Services
>>
>> *Skype*: timlinux 
>> *IRC:* timlinux on #qgis at freenode.net 
>>
>
>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Preview job and slow datasources

[Patrick Dunford]

So to put it another way this is the reason why Qgis wants to use a huge 
amount of memory (40 GB) when I have a lot of raster images loaded in 
the background.



On 16/11/17 18:56, Tim Sutton wrote:

Hi

On 16 Nov 2017, at 04:35, Patrick Dunford > wrote:


What is this "preview job" function?




Its application logic to prefetch / pre-render offscreen content in 
anticipation of user panning the map.


Regards

Tim


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org 
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


—






*Tim Sutton*

*Co-founder:*Kartoza
*Project chair:*QGIS.org 

Visit http://kartoza.com  to find out about open 
source:


Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

*Skype*: timlinux
*IRC:*timlinux on #qgis at freenode.net 



___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] On the danger of static C++ objects

[Tim Sutton]

Hi Even

> On 16 Nov 2017, at 00:58, Even Rouault  wrote:
> 
> Hi,
>  
> There was a frequent crash in PyQgsServerWMS on Travis that I've hopefully 
> fixed per 
> https://github.com/qgis/QGIS/commit/581d0d30ca89a213b1ba1a56a3fe2af5c896eacd 
> 
>  
> This is the opportunity to raise attention on the danger of using this 
> pattern:
>  
> static SomeClass singletonInstance;
>  
> where ~SomeClass() does some non trivial work in its destructor, and in 
> particular calling other libraries (such as in the above mentionned case). 
> Depending on the order into which libraries are unloaded and objects 
> destroyed,  ~SomeClass() might call a function of a library which has already 
> been unloaded, leading to crash.
>  
> So I'd suggest rather using a pointer approach (which admitedly makes 
> constructing the singleton in a thread-safe way a bit harder), and explicitly 
> deleting the singleton at appropriate and explicit time.
>  
> Unless someone is aware of a better approach.
>  
> By the way, is there somewhere in the tree a developer guide where we can 
> collect such knowledge ?

We have:

https://www.qgis.org/en/site/getinvolved/development/qgisdevelopersguide/index.html

Source for which is here:

There is a ‘fix me’ link in the bottom of each page in the guide which will 
take you to the sphinx sources.

Regards

Tim

>  
> Even
>  
> -- 
> Spatialys - Geospatial professional services
> http://www.spatialys.com 
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org 
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer 
> 
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer 
> 
—







Tim Sutton

Co-founder: Kartoza
Project chair: QGIS.org

Visit http://kartoza.com  to find out about open source:

Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

Skype: timlinux 
IRC: timlinux on #qgis at freenode.net

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Preview job and slow datasources

[Tim Sutton]

Hi

> On 16 Nov 2017, at 04:35, Patrick Dunford  wrote:
> 
> What is this "preview job" function?
> 
> 

Its application logic to prefetch / pre-render offscreen content in 
anticipation of user panning the map.

Regards

Tim
> 
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

—







Tim Sutton

Co-founder: Kartoza
Project chair: QGIS.org

Visit http://kartoza.com  to find out about open source:

Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

Skype: timlinux 
IRC: timlinux on #qgis at freenode.net

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Preview job and slow datasources

[Patrick Dunford]

What is this "preview job" function?


On 16/11/17 03:56, Even Rouault wrote:


Hi,

I'm working currently on improving raster performance per

https://github.com/qgis/QGIS/pull/5632 , and while testing with a 
variety of GDAL datasources, I found that the "preview job" (*) 
mechanism that is currently enabled on the main canvas (pre-rendering 
the 8 zones around the canvas extent) can have adverse performance 
impact with very slow datasources. Particularly those doing network 
accesses, where the bandwidth consumed by the preview jobs prevents 
the main rendering job to being served first (due to the fact the the 
preview jobs of the previous interaction are not immediately cancelled 
by the next one since, because being busy in libcurl calls)


Wouldn't it make sense to offer an option to disable preview jobs on 
the main canvas for such use case ?


I guess this could also be useful for complex projects with many 
layers of "fast datasources", but where the global rendering time is 
large.


A clever variant would measure the execution time of those preview 
jobs, and if, for example, it is above the 250 ms delay in which they 
are fired by QgsMapCanvas::schedulePreviewJob(), it would 
automatically disable it (potentially, temporarily, until the number 
of layers changes). In the case I mentionned above, each preview job 
takes several seconds to complete.


Or a simpler alternative would be to schedule the next preview job 
after the previous preview job has completed (instead of starting them 
every 250 ms). This would not be completely ideal with my above 
mentionned network case, compared to completely disabling preview 
jobs, but that could be a reasonable compromise, and would limit the 
CPU load of preview jobs to at most one core (currently if the preview 
jobs run slowly, they can "eat" up to 8 cores, since they are 8 
preview jobs)




___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] On the danger of static C++ objects

[Even Rouault]

Hi,

There was a frequent crash in PyQgsServerWMS on Travis that I've hopefully 
fixed per 
https://github.com/qgis/QGIS/commit/581d0d30ca89a213b1ba1a56a3fe2af5c896eacd

This is the opportunity to raise attention on the danger of using this pattern:

static SomeClass singletonInstance;

where ~SomeClass() does some non trivial work in its destructor, and in 
particular calling 
other libraries (such as in the above mentionned case). Depending on the order 
into which 
libraries are unloaded and objects destroyed,  ~SomeClass() might call a 
function of a 
library which has already been unloaded, leading to crash.

So I'd suggest rather using a pointer approach (which admitedly makes 
constructing the 
singleton in a thread-safe way a bit harder), and explicitly deleting the 
singleton at 
appropriate and explicit time.

Unless someone is aware of a better approach.

By the way, is there somewhere in the tree a developer guide where we can 
collect such 
knowledge ?

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Preview job and slow datasources

[Nyall Dawson]

On 16 November 2017 at 00:56, Even Rouault  wrote:
> Wouldn't it make sense to offer an option to disable preview jobs on the
> main canvas for such use case ?

I agree with Matthias here, in that we want to avoid adding a
user-configurable option for this. Either we can get the preview jobs
tamed and stable enough to always enable, or we ifdef them out and
leave them to a future release.

> A clever variant would measure the execution time of those preview jobs, and
> if, for example, it is above the 250 ms delay in which they are fired by
> QgsMapCanvas::schedulePreviewJob(), it would automatically disable it
> (potentially, temporarily, until the number of layers changes). In the case
> I mentionned above, each preview job takes several seconds to complete.

I like it!

> Or a simpler alternative would be to schedule the next preview job after the
> previous preview job has completed (instead of starting them every 250 ms).

I think both approaches could be done to ease the burden of these
jobs. I'm thinking that possibly there's cases were individual layer
renders take < 250ms, but all together the total render time still
exceeds the 250ms timeout (e.g. due to large number of layers being
rendered). In this case we should still avoid having multiple preview
jobs being rendered at once.

On that note, in Nodebo Martin suggested that if we had a limit of one
preview job at a time we could intelligently prioritise these too.
E.g. the first job is the done in the same direction as the last
canvas move (assuming the next move will be in the same direction - "i
didn't move far enough"), then the opposite direction ("oops, went too
far"), and then the rest of the jobs...

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Preview job and slow datasources

[Nyall Dawson]

On 16 November 2017 at 04:58, Richard Duivenvoorde  wrote:
>
> Is it possible that these preview-jobs are responsible for the WMTS
> crashes which are reported in master (and I have myself pretty often)?
>

Not responsible for them, but they may make an existing issue more
frequent by stress-testing how thread safe different code paths are.
That's why a few months back the decision was made to leave the
preview jobs as resource demanding to try and expose these issues.

But now that we're closing in on release I agree that we need to
ensure that there's no performance regressions caused by these jobs.

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Preview job and slow datasources

[Even Rouault]

> Is it possible that these preview-jobs are responsible for the WMTS
> crashes which are reported in master (and I have myself pretty often)?
> 
> https://issues.qgis.org/issues/16966#change-84394
> 
> At least for WMST I would find retrieving 8 times the number of
> images/requests too much? I pretty often have several WMS or WMST layers
> in the a layerlist.

Loosely related, but that could occur without job previewing as well. Given the 
crash 
stack traces I got, seems to be a thread-safety issue with QgsAuthManager use.
PR https://github.com/qgis/QGIS/pull/5646 submitted


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Preview job and slow datasources

[Richard Duivenvoorde]

On 15-11-17 17:11, Matthias Kuhn wrote:

> Other factors that could be considered are things like how long it takes
> to cancel an ongoing rendering job or how many free connections we have
> in the pool.
> E.g. in the case of a WMST, the time to build the image might be high
> (as long as it's not coming from the cache) but it's worth preloading
> and showing in any case.

Is it possible that these preview-jobs are responsible for the WMTS
crashes which are reported in master (and I have myself pretty often)?

https://issues.qgis.org/issues/16966#change-84394

At least for WMST I would find retrieving 8 times the number of
images/requests too much? I pretty often have several WMS or WMST layers
in the a layerlist.

Regards,

Richard Duivenvoorde

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Is the map preview in CRS selector dialog broken?

[DelazJ]

Hi devs,

In QGIS 3, in the CRS Selector dialog of a layer (or global setting),
there's a map preview (thanks Nathan) [0].
Whatever CRS I select, in the first or the second table of CRSs, the map
preview always shows the whole world with a cross at the "center"[1]. I'm
on windows 10.
I'd expect it to zoom to the extent of the selected crs, lika a help tool
to select compatible crs with working zone.
Did I misunderstand? Otherwise,am i just impatient or is there a bug I
should report?

Regards,
Harrissou

[0] https://github.com/qgis/QGIS/pull/5356
[1] Actually, it shows the world when it's opened from layer properties
dialog (or options dialog) and the map canvas extent when in project
properties dialog.
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Preview job and slow datasources

[Matthias Kuhn]

On 11/15/2017 04:55 PM, Even Rouault wrote:
> On mercredi 15 novembre 2017 16:18:29 CET Matthias Kuhn wrote:
> 
> 
> So if the provider of one layer returns false in renderInPreview() that
> would disable the rendering of those layers in the preview images ?

Disabling only certain layers individually will help to get some cheap
layers show up to help with navigation.
 
> 
>> or just blacklists some known-expensive types?
> 
>  
> 
> The provider has not necessarily that knowledge. In my example, if you
> are very close to the server and have high bandwidth, preview jobs
> wouldn't be a bottleneck.
> 
> Or there are cases like JPEG2000 where the CPU speed and number of cores
> can make a huge difference, so the knowledge of the GDAL driver isn't
> enough.

> 
> So I'm wondering if just a per-layer timing logic in
> QgsMapRendererCustomPainterJob::doRender() wouldn't be enough.

Other factors that could be considered are things like how long it takes
to cancel an ongoing rendering job or how many free connections we have
in the pool.
E.g. in the case of a WMST, the time to build the image might be high
(as long as it's not coming from the cache) but it's worth preloading
and showing in any case.
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Preview job and slow datasources

[Even Rouault]

On mercredi 15 novembre 2017 16:18:29 CET Matthias Kuhn wrote:
> Hi Even,
> 
> we have shortly discussed this topic in the past and the general
> consensus was, not to offer such an option (which is easy to forget and
> hard to set right without deep knowledge).
> 
> Should we consider a `virtual QgsDataProvider::renderInPreview()`
> method, that can be finetuned by each provider and has a default
> implementation that either uses rendering times as heuristics 

So if the provider of one layer returns false in renderInPreview() that would 
disable the 
rendering of those layers in the preview images ?

> or just blacklists some known-expensive types?

The provider has not necessarily that knowledge. In my example, if you are very 
close to the 
server and have high bandwidth, preview jobs wouldn't be a bottleneck.
Or there are cases like JPEG2000 where the CPU speed and number of cores can 
make a huge 
difference, so the knowledge of the GDAL driver isn't enough.

So I'm wondering if just a per-layer timing logic in 
QgsMapRendererCustomPainterJob::doRender() wouldn't be enough.

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Preview job and slow datasources

[Matthias Kuhn]

Hi Even,

we have shortly discussed this topic in the past and the general
consensus was, not to offer such an option (which is easy to forget and
hard to set right without deep knowledge).

Should we consider a `virtual QgsDataProvider::renderInPreview()`
method, that can be finetuned by each provider and has a default
implementation that either uses rendering times as heuristics or just
blacklists some known-expensive types?

Matthias

On 11/15/2017 03:56 PM, Even Rouault wrote:
> Hi,
> 
>  
> 
> I'm working currently on improving raster performance per
> 
> https://github.com/qgis/QGIS/pull/5632 , and while testing with a
> variety of GDAL datasources, I found that the "preview job" (*)
> mechanism that is currently enabled on the main canvas (pre-rendering
> the 8 zones around the canvas extent) can have adverse performance
> impact with very slow datasources. Particularly those doing network
> accesses, where the bandwidth consumed by the preview jobs prevents the
> main rendering job to being served first (due to the fact the the
> preview jobs of the previous interaction are not immediately cancelled
> by the next one since, because being busy in libcurl calls)
> 
>  
> 
> Wouldn't it make sense to offer an option to disable preview jobs on the
> main canvas for such use case ?
> 
> I guess this could also be useful for complex projects with many layers
> of "fast datasources", but where the global rendering time is large.
> 
>  
> 
> A clever variant would measure the execution time of those preview jobs,
> and if, for example, it is above the 250 ms delay in which they are
> fired by QgsMapCanvas::schedulePreviewJob(), it would automatically
> disable it (potentially, temporarily, until the number of layers
> changes). In the case I mentionned above, each preview job takes several
> seconds to complete.
> 
>  
> 
> Or a simpler alternative would be to schedule the next preview job after
> the previous preview job has completed (instead of starting them every
> 250 ms). This would not be completely ideal with my above mentionned
> network case, compared to completely disabling preview jobs, but that
> could be a reasonable compromise, and would limit the CPU load of
> preview jobs to at most one core (currently if the preview jobs run
> slowly, they can "eat" up to 8 cores, since they are 8 preview jobs)
> 
>  
> 
> Thoughts ?
> 
>  
> 
> Even
> 
>  
> 
> (*) added per
> 
> https://github.com/qgis/qgis/commit/2d531e5814c1b43a23c36d09ace9a5f5729e5bb4
> 
>  
> 
> -- 
> 
> Spatialys - Geospatial professional services
> 
> http://www.spatialys.com
> 
> 
> 
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Preview job and slow datasources

[Even Rouault]

Hi,

I'm working currently on improving raster performance per
https://github.com/qgis/QGIS/pull/5632 , and while testing with a variety of 
GDAL 
datasources, I found that the "preview job" (*) mechanism that is currently 
enabled on the 
main canvas (pre-rendering the 8 zones around the canvas extent) can have 
adverse 
performance impact with very slow datasources. Particularly those doing network 
accesses, 
where the bandwidth consumed by the preview jobs prevents the main rendering 
job to 
being served first (due to the fact the the preview jobs of the previous 
interaction are not 
immediately cancelled by the next one since, because being busy in libcurl 
calls)

Wouldn't it make sense to offer an option to disable preview jobs on the main 
canvas for such 
use case ?
I guess this could also be useful for complex projects with many layers of 
"fast datasources", 
but where the global rendering time is large.

A clever variant would measure the execution time of those preview jobs, and 
if, for example, 
it is above the 250 ms delay  in which they are fired by 
QgsMapCanvas::schedulePreviewJob(), it would automatically disable it 
(potentially, 
temporarily, until the number of layers changes). In the case I mentionned 
above, each 
preview job takes several seconds to complete.

Or a simpler alternative would be to schedule the next preview job after the 
previous 
preview job has completed (instead of starting them every 250 ms).  This would 
not be 
completely ideal with my above mentionned network case, compared to completely 
disabling 
preview jobs, but that could be a reasonable compromise, and would limit the 
CPU load of 
preview jobs to at most one core (currently if the preview jobs run slowly, 
they can "eat" up 
to 8 cores, since they are 8 preview jobs)

Thoughts ?

Even

(*) added per
https://github.com/qgis/qgis/commit/2d531e5814c1b43a23c36d09ace9a5f5729e5bb4

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Minimum SpatiaLite version 4.2

[Mark Johnson]

For compiling, that should be no problem.

Since 4.3 has been out for 2 years and contains many new features, I would
even say 4.3.

But for the reading of Databases from older versions and running with older
versions is problematic.

The present QgsSpatiaLiteProvider does not deal with this well, whereas the
proposed new version (for QGis 3.2) does.

Mark Johnson, Berlin Germany
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Processing Split with lines algorithm broken

[G. Allegri]

I also agree to step back to single-part output.

giovanni

2017-11-15 11:13 GMT+01:00 Alexandre Neto :

> +1
>
> Nathan Woodrow  escreveu no dia quarta, 15/11/2017
> às 05:10:
>
>> IMO go with the principle of least astonishment.  I think the expected
>> outcome is single part features as it's not clear that you need to run
>> another step.
>>
>> - Nathan
>>
>> On Wed, Nov 15, 2017 at 2:48 PM, Nyall Dawson 
>> wrote:
>>
>>> On 15 November 2017 at 00:33, matteo  wrote:
>>> > Hi devs,
>>> >
>>> > the algorithm Split with lines seems not working. No output error but
>>> > both lines or polygons in output are not split. The same algorithm with
>>> > the same data works in QGIS 2.18
>>>
>>> I suspect it's working OK, but you're hitting a change in 3.0 where
>>> the output of this algorithm is a multi-line, with the individual
>>> split parts still forming a single feature. You need to run multiparts
>>> to singleparts on it afterward.
>>>
>>> However
>>>
>>> This was a change I requested in
>>> https://github.com/qgis/QGIS/pull/3798, since it seemed like a logical
>>> move. Having used this algorithm extensively since (and also been
>>> confused in thinking that the algorithm was broken!) I'm not convinced
>>> this was the right move anymore, and think that we should probably
>>> always output single-part features from this algorithm.
>>>
>>> What's everyone's thoughts?
>>>
>>> Nyall
>>> ___
>>> QGIS-Developer mailing list
>>> QGIS-Developer@lists.osgeo.org
>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> --
> Alexandre Neto
> -
> @AlexNetoGeo
> http://sigsemgrilhetas.wordpress.com
> http://gisunchained.wordpress.com
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Processing Split with lines algorithm broken

[Alexandre Neto]

+1

Nathan Woodrow  escreveu no dia quarta, 15/11/2017 às
05:10:

> IMO go with the principle of least astonishment.  I think the expected
> outcome is single part features as it's not clear that you need to run
> another step.
>
> - Nathan
>
> On Wed, Nov 15, 2017 at 2:48 PM, Nyall Dawson 
> wrote:
>
>> On 15 November 2017 at 00:33, matteo  wrote:
>> > Hi devs,
>> >
>> > the algorithm Split with lines seems not working. No output error but
>> > both lines or polygons in output are not split. The same algorithm with
>> > the same data works in QGIS 2.18
>>
>> I suspect it's working OK, but you're hitting a change in 3.0 where
>> the output of this algorithm is a multi-line, with the individual
>> split parts still forming a single feature. You need to run multiparts
>> to singleparts on it afterward.
>>
>> However
>>
>> This was a change I requested in
>> https://github.com/qgis/QGIS/pull/3798, since it seemed like a logical
>> move. Having used this algorithm extensively since (and also been
>> confused in thinking that the algorithm was broken!) I'm not convinced
>> this was the right move anymore, and think that we should probably
>> always output single-part features from this algorithm.
>>
>> What's everyone's thoughts?
>>
>> Nyall
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 
Alexandre Neto
-
@AlexNetoGeo
http://sigsemgrilhetas.wordpress.com
http://gisunchained.wordpress.com
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Merging raster-save dialog change and Windows workflow

[Jürgen E . Fischer]

Hi,

On Wed, 15. Nov 2017 at 01:02:48 +, Tisham Dhar wrote:
> 1)  Checkout as standard on windows with git-bash (line endings are an
> issue). Will have to try a fresh clone in WLS to see what difference
> it makes

Why not cygwin?  That's what I use and recommend.   WLS means WSL?


Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de


signature.asc
Description: PGP signature
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Minimum SpatiaLite version 4.2

[Matthias Kuhn]

Hi devs,

I just proposed an upgrade to SpatiaLite>=4.2 requirement on QGIS 3
(https://github.com/qgis/QGIS/pull/5636)

Is there anyone requiring support for older versions? If yes, we can
also keep compatibility with 4.0/4.1 and just drop code for <4.0 (I
guess that's really outdated nowadays)

Thanks for feedback and best regards

Matthias

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Processing Split with lines algorithm broken

[matteo]

Hi Nyall,


> I suspect it's working OK, but you're hitting a change in 3.0 where
> the output of this algorithm is a multi-line, with the individual
> split parts still forming a single feature. You need to run multiparts
> to singleparts on it afterward.

uh... sorry I missed that the multipart is now the output.

However, I think that users (me included) is expecting single part
features as output. I was really confused yesterday and as you can seen
I thought that the algorithm was broken.

So +1 for me to single part output

Thanks for the clarification

Cheers

Matteo
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer