[QGIS-Developer] Best practices for storing plugin settings

[Gabriel De Luca via QGIS-Developer]

Hello everyone,

  I'm developing a plugin and I'm not sure where to write the settings.

  Should I create the settings object with my own organization and
application? I would expect a plugin's settings to be stored in the profile
folder where the plugin is installed, within the same qgis configurations
file, so it doesn't seem like a good option to me.

  If I write the settings under the same organization and application as
QGIS, is it appropriate to create a root group for my plugin? All the
plugins I have installed did that, but for some reason they are hidden when
viewing the advanced settings with the new tree widget.

  Is the "plugins" group appropriate to create a sub-group/key with the
name of my plugin?

  The only email I found in the archive referring to the settings structure
is [1], I'll keep it in mind when it comes to group/key names, but any
other recommendations on good practices for third-party plugins are welcome.


Regards,
Gabriel

[1] https://lists.osgeo.org/pipermail/qgis-developer/2017-March/047487.html
___
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] Dropping "render" checkbox from status bar

[Nicolas Cadieux via QGIS-Developer]

Hi,

Still useful on my side when rendering very heavy stuff and then decide to zoom 
to another part of the map… 

Nicolas Cadieux

> Le 15 oct. 2023 à 15:30, Nyall Dawson via QGIS-Developer 
>  a écrit :
> 
> Hi list,
> 
> Question: are there still any valid use cases for the "render"
> checkbox in the status bar? It's been around forever, and DID have a
> strong use case when map rendering used to block the QGIS interface.
> But is there any reason to keep this around in modern QGIS versions?
> 
> 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

Re: [QGIS-Developer] QGIS repository management

[Nyall Dawson via QGIS-Developer]

For completeness:

> - an approved member CANNOT approve their own changes
> - an approved member CAN approve a complete stranger's changes
> - an approved member CAN approve a another approved member's changes

A potential issue which has popped up a couple of times is whether
it's acceptable for another staff member from the same organisation to
approve their colleague's PRs. Is this acceptable or not? Is it a
conflict of interest? Does it lean toward lenient reviews and getting
a speedy merge? Or is it good practice because the organisation isn't
placing any burden on others outside of their organization? 路 Who
knows! But definitely work discussing if we are writing up formal
policies...

Nyall






>
> I think the misunderstanding is all about naming. If we drop the
> confusing "core committer" label and change it to "approved reviewer",
> then everything becomes clear.
>
> (and then we have a separate "super user" group with repo admin level
> privileges, which should be kept as SMALL as possibly needed to keep
> the repository and CI working, and is unrelated to
> code/trust/experience/etc...)
>
> > Another policy I believe in is that whoever is allowed to apply
> > changes to the repository should take on the responsibility of
> > fixing bugs introduced by those changes.
>
> I'm a hesitant +0 to this. I do think we've all got a good track
> record of fixing our own mistakes within reasonable expectations. I'd
> be concerned that formalising this would put a lot of unreasonable
> expectations on developers (where's the limit? If it's found that I
> broke some esoteric workflow not covered by unit tests 3 years later,
> am I still responsible for fixing that? I'd argue not).
>
> Nyall
> >
> > --strk;
___
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] QGIS repository management

[Nyall Dawson via QGIS-Developer]

On Mon, 16 Oct 2023 at 09:44, Sandro Santilli  wrote:
>
> On Mon, Oct 16, 2023 at 08:58:30AM +1300, Nyall Dawson wrote:
> > On Sat, 14 Oct 2023 at 05:43, Sandro Santilli wrote:
> >
> > >   2. Allow those with "write access" to self-approve PRs
> >
> > -1. What's the real motivation here? Why the urgency to get unreviewed code
> > into QGIS?
>
> A recent example of urgency: I broke the pre-commit hook for most
> developers, I could have pushed the fix earlier if I didn't have
> to wait for a review.

That's a fair example, I'll concede that point! I wonder if tagging
the commit with "[skip ci]" would still permit the merge request to be
merged? It's worth a test.

>
> The other motivation is not about urgency but about a conflicting policy:
>
>   - I can be the _only_ reviewer approving a complete stranger's
> proposed change.
>
>   - I can NOT be the _only_ reviewer approving my proposed change.
>
> Is trust given to _me_ as a "reviewer" or not ?
> It is in the first case, it isn't in the second case.

If you flip the situation, you'll see that yes, you do have trust!

- a complete stranger CANNOT approve their own changes
- a complete stranger CANNOT approve other stranger's changes
- a complete stranger CANNOT approve an approved member's changes

vs

- an approved member CANNOT approve their own changes
- an approved member CAN approve a complete stranger's changes
- an approved member CAN approve a another approved member's changes

I think the misunderstanding is all about naming. If we drop the
confusing "core committer" label and change it to "approved reviewer",
then everything becomes clear.

(and then we have a separate "super user" group with repo admin level
privileges, which should be kept as SMALL as possibly needed to keep
the repository and CI working, and is unrelated to
code/trust/experience/etc...)

> Another policy I believe in is that whoever is allowed to apply
> changes to the repository should take on the responsibility of
> fixing bugs introduced by those changes.

I'm a hesitant +0 to this. I do think we've all got a good track
record of fixing our own mistakes within reasonable expectations. I'd
be concerned that formalising this would put a lot of unreasonable
expectations on developers (where's the limit? If it's found that I
broke some esoteric workflow not covered by unit tests 3 years later,
am I still responsible for fixing that? I'd argue not).

Nyall
>
> --strk;
___
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] QGIS repository management

[Sandro Santilli via QGIS-Developer]

On Mon, Oct 16, 2023 at 09:04:38AM +1300, Nyall Dawson wrote:

> I have this power too -- and I use it on a daily basis to keep the whole CI
> setup flowing (ie restarting workflows in other's PRs, merging approved PRs
> when an unrelated workflow failure has blocked a merge, etc).
> 
> I'd like to point out that it's only used to keep the project humming along
> for EVERYONE's benefit -- it's not a conspiracy to create a set of "super
> committers" with extra power  .

I know you're not doing any evil, I just find it useful to know who
has those powers so I know who to ask to if I need them :)

--strk;
___
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] QGIS repository management

[Sandro Santilli via QGIS-Developer]

On Mon, Oct 16, 2023 at 08:58:30AM +1300, Nyall Dawson wrote:
> On Sat, 14 Oct 2023 at 05:43, Sandro Santilli wrote:
>
> >   2. Allow those with "write access" to self-approve PRs
> 
> -1. What's the real motivation here? Why the urgency to get unreviewed code
> into QGIS?

A recent example of urgency: I broke the pre-commit hook for most
developers, I could have pushed the fix earlier if I didn't have
to wait for a review.

The other motivation is not about urgency but about a conflicting policy:

  - I can be the _only_ reviewer approving a complete stranger's
proposed change.

  - I can NOT be the _only_ reviewer approving my proposed change.

Is trust given to _me_ as a "reviewer" or not ?
It is in the first case, it isn't in the second case.

> Again, I am strongly of the opinion that more exhaustive code
> merging policies protects our users and their trust in QGIS.

I'm not against policies per-se. For example I'm strongly of the
opinion that those who propose changes should run as many tests
as possible to verify the effects of those changes, and would give
high priority to tasks that aim at making this test runs as smooth
as possible.

Another policy I believe in is that whoever is allowed to apply
changes to the repository should take on the responsibility of
fixing bugs introduced by those changes.

--strk;
___
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] QGIS repository management

[Nyall Dawson via QGIS-Developer]

On Sun, 15 Oct 2023 at 02:54, Sandro Santilli via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:
>
> That term "committer", btw, should probably be changed nowadays as
> with git it doesnt' make much sense.

+1. Maybe we should go with "review approver" to reflect exactly what this
privilege means today...

>
> > The QGIS organization has a budget for PR queue management (triage)
> > and a separate entry for reviews (budget is public
> > https://www.qgis.org/en/site/getinvolved/governance/finance/index.html)
> > , in the past this has been working well while I agree that recently
> > PRs have been pending without review for a (too) long time.
>
> The bugfixing spreadsheet has a column to report reviewer names,
> but it looks like I'm the only one filling it at the moment.
> You may notice I've also reported reviews from non-committers
> ( Laurențiu Nicola, in Cc ).

I think everyone is trying to reduce paperwork and that's why that column
is unpopulated 

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] QGIS repository management

[Nyall Dawson via QGIS-Developer]

> A small group of us (3-4 developers including me) have admin access to
> all QGIS repositories and we can bypass any check and merge all PRs
> without approval.

I have this power too -- and I use it on a daily basis to keep the whole CI
setup flowing (ie restarting workflows in other's PRs, merging approved PRs
when an unrelated workflow failure has blocked a merge, etc).

I'd like to point out that it's only used to keep the project humming along
for EVERYONE's benefit -- it's not a conspiracy to create a set of "super
committers" with extra power  .

Nyall


>
> I admit that I have been using these superpowers more and more often
> (IIRC three or four times) in the last year while I have never felt
> the need to use them before, in an ideal world it should not be
> necessary except for the same use cases I have pointed out for the
> direct pushes to master.
>
> The bottom line is that the situation is not perfect and can certainly
> be improved but at the end of the day we are all doing our best to
> keep the process running as smoothly as we can.
>
> Thank you for raising this point, you are absolutely right that it
> should be clearly documented, this has been in our TODO list for a
> long time.
>
> Best regards.
>
>
> On Fri, Oct 13, 2023 at 6:42 PM Sandro Santilli via QGIS-Developer
>  wrote:
> >
> > Hello all,
> > today I was finally able to more clearly see the problem that frustrates
> > me everytime a take part to a new QGIS bugfixing drive, and I would like
> > to share it hoping to find a solution togheter.
> >
> > The main problem:
> >
> >   - Despite having been granted write access to the QGIS repository in
2012
> > [1], I cannot effectively use that power today
> >
> > It's not just me, I think, but I cannot tell for sure because the
configuration
> > of the infrastructure currently in use (github) is not available for me
to see
> > and the governance page on the official QGIS website does not contain
this
> > information [2]. This being blind of course adds up to my frustration.
> >
> > From experience, I know that the reason why I cannot write to the QGIS
> > repository is because "branch protection" is active (for the master
branch
> > at least) and a set of conditions are required to merge a PR, namely:
> >
> >   - All CI tests need to pass.
> >
> >   - Someone else (I don't know from which group of people) needs to
> > approve the proposed change.
> >
> > While I do the above condition being a useful indication for "QGIS
> > core developers" to decide whether to accept or not a change request,
> > I find them representing an obstacle way more often than a service,
> > and in particular:
> >
> > 1. CI is often broken for reasons that are independent from the proposed
> >change.
> >
> > 2. An aberration of the "review" condition is that a change proposed by
a
> >contributor and approved by me can be merged but a change proposed by
> >me and approved by the same contributor can not be merged,
effectively
> >giving me ("core QGIS committer") less power than the power of a
random
> >contributor.
> >
> > The rules described above are not found from the governance page [2]
> > so it isn't easy for me to propose changes because I don't have a clear
> > picture of current rules (like, I believe some people in QGIS can
> > self-approve PRs but dunno how to tell who and why).
> >
> > I would personally welcome (and be able to help taking) the following
actions:
> >
> >   1. Clearly document the roles and rules on the website
> >
> >   2. Allow those with "write access" to self-approve PRs
> >
> >   3. Define rules by which "write access" privileges to the repository
> >  are revoked
> >
> > Thanks for having read this in full, and I hope to hear your position
> > on the matter.  Happy hacking !
> >
> >
> > [1]
https://lists.osgeo.org/pipermail/qgis-developer/2012-October/022715.html
> > [2] https://qgis.org/en/site/getinvolved/governance/governance.html
> >
> > --strk;
> >
> >   Libre GIS consultant/developer
> >   https://strk.kbt.io/services.html
> > ___
> > 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
>
>
>
> --
> Alessandro Pasotti
> QCooperative:  www.qcooperative.net
> ItOpen:   www.itopen.it
> ___
> 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] Dropping "render" checkbox from status bar

[steven kay via QGIS-Developer]

Yes! I find this useful, sometimes.

Use case: Sometimes I'll use the Db manager to write a query which I add as
a view. With a few million points. Said layer is created dynamically, so it
takes a while to render with the default symbology.

If I can turn off rendering, I don't need to wait for ages for it to
render, I can select the layer and export it as a GPKG, and then import it.

At no point does QGIS GUI become unresponsive - I can just uncheck the box.

I just don't want to wait around for a render I don't need

I hope that makes sense! I'm sure there's a better way in QGIS I'm not
aware of :)

Steven

On Sun, Oct 15, 2023 at 8:39 PM Vedran Stojnović via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:

> Hi Nyall,
>
> I find it useful from time to time with complex layer rendering when it
> takes several seconds or more to render a map canvas and I want to
> investigate attributes currently shown on screen.
>
> My procedure is as follows:
> 1) zoom at the appropriate level and lock rendering
> 2) open the attribute table and set it to display items visible on the map
> 3) move around the map zooming in and out and analyzing the results
>
>
> ned, 15. lis 2023. u 21:30 Nyall Dawson via QGIS-Developer <
> qgis-developer@lists.osgeo.org> napisao je:
>
>> Hi list,
>>
>> Question: are there still any valid use cases for the "render"
>> checkbox in the status bar? It's been around forever, and DID have a
>> strong use case when map rendering used to block the QGIS interface.
>> But is there any reason to keep this around in modern QGIS versions?
>>
>> 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
>>
>
>
> --
> Srdačan pozdrav / Kind regards,
> Vedran Stojnović.
> ___
> 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] QGIS repository management

[Nyall Dawson via QGIS-Developer]

Hi Sandro,

Thanks for raising this discussion. I'll add my knowledge inline below.

But please keep in mind that all this stuff has just been set over time in
a reactionary/evolutionary process to keep things running smoothly, rather
than something which was designed and formalised by a committee in advance.
There's always room for improvement and revision to match current needs! 

On Sat, 14 Oct 2023 at 05:43, Sandro Santilli via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:
>
> It's not just me, I think, but I cannot tell for sure because the
configuration
> of the infrastructure currently in use (github) is not available for me
to see
> and the governance page on the official QGIS website does not contain this
> information [2]. This being blind of course adds up to my frustration.

This page **definetly** needs an update. There's information on that page
which is ~decades out of date (eg Larry Shaffer hasn't been involved in the
project for around 10 years, the OSX packaging team is incorrect, and the
whole "testing" team is non-existent, etc).

I'm happy to help out here with removing old content. My gut feeling is
that a more exhaustive rework is needed and repository / process related
information doesn't belong on this page, and the page should be left to the
"organisation" level governance information alone.

> From experience, I know that the reason why I cannot write to the QGIS
> repository is because "branch protection" is active (for the master branch
> at least) and a set of conditions are required to merge a PR, namely:
>
>   - All CI tests need to pass.
>
>   - Someone else (I don't know from which group of people) needs to
> approve the proposed change.

Correct. And I would argue that both of these requirements are a valid
**MINIMUM** protection choice for introducing code into a project which has
real world cost impacts for users exceeding millions and potentially
impacting the lives and safety of others.

> 1. CI is often broken for reasons that are independent from the proposed
>change.

Definitely a valid issue, and a real PITA. I'm probably restarting that
mingw workflow ~20x a day for everyone's(!) PRs to keep it limping along.

That said, I'd still rather limp this workflow along vs removing it,
because I do believe that it adds value to our tests and gives end users an
easy way to test PRs prior to merge. I feel the same about the noisy
clang-tidy check: it has a LOT of false positives, but around 1 in 10
failures in that workflow is a valid bug which has been flagged prior to
introducing the code. That's still a net win in my view.

> 2. An aberration of the "review" condition is that a change proposed by a
>contributor and approved by me can be merged but a change proposed by
>me and approved by the same contributor can not be merged, effectively
>giving me ("core QGIS committer") less power than the power of a random
>contributor.

Maybe -- but I would argue that you're looking at the "core contributor"
privilege incorrectly. It's no longer a "you are trusted to put whatever
code you want into the project" vs a "you are trusted to peer review and
approve code proposed for introduction into the project".

Ie **everyone** is on the same level wrt to submitting code for review, but
only the trusted group of core committers are permitted to approve this
code for introduction to QGIS.

>   1. Clearly document the roles and rules on the website

+1

>   2. Allow those with "write access" to self-approve PRs

-1. What's the real motivation here? Why the urgency to get unreviewed code
into QGIS? Again, I am strongly of the opinion that more exhaustive code
merging policies protects our users and their trust in QGIS.

>   3. Define rules by which "write access" privileges to the repository
>  are revoked

+1

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] Dropping "render" checkbox from status bar

[Vedran Stojnović via QGIS-Developer]

Hi Nyall,

I find it useful from time to time with complex layer rendering when it
takes several seconds or more to render a map canvas and I want to
investigate attributes currently shown on screen.

My procedure is as follows:
1) zoom at the appropriate level and lock rendering
2) open the attribute table and set it to display items visible on the map
3) move around the map zooming in and out and analyzing the results


ned, 15. lis 2023. u 21:30 Nyall Dawson via QGIS-Developer <
qgis-developer@lists.osgeo.org> napisao je:

> Hi list,
>
> Question: are there still any valid use cases for the "render"
> checkbox in the status bar? It's been around forever, and DID have a
> strong use case when map rendering used to block the QGIS interface.
> But is there any reason to keep this around in modern QGIS versions?
>
> 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
>


-- 
Srdačan pozdrav / Kind regards,
Vedran Stojnović.
___
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] Dropping "render" checkbox from status bar

[Nyall Dawson via QGIS-Developer]

Hi list,

Question: are there still any valid use cases for the "render"
checkbox in the status bar? It's been around forever, and DID have a
strong use case when map rendering used to block the QGIS interface.
But is there any reason to keep this around in modern QGIS versions?

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] QGIS 3D and Graphics Card Requirements

[Bernd Vogelgesang via QGIS-Developer]

Hi,

my 2 cents from a 3D-interested (not yet experienced) user:
1. doing GIS-stuff on a notebook, no matter how performant it is, for me
is a PITA.
Clumsy keyboards, overpriced hardware. GIS-work without a large or 2
screens is useless -> so whats the point of a mobile computer then?

2. Had a 10 year old mid-range gaming computer so far (i7 4770k, 16GGB
RAM, 2GB Graphics card).
For any usage in 2D this was still more than sufficient.
Native QGIS 3D crashed.
Sniffed a bit into Blender, which had much better performance, but the
workflow to use it efficiently with real world data is still unclear to me.

3. As my pockets are full, I am in the process to order a NVIDIA RTX
4090 and will be reporting back about the finding.

4. What I would wish for the 3D-future of QGIS: Somehow wire into the
Blender 3D capabilities.
Usecase: For planning processes of construction (Windmills, solar farms,
Buildings, bridges etc.):
(Semi-)realistic landscapes based on geodata and aerial images, but
pimped up with 3D-model bushes, trees etc based on semi-automatic
classification of aerial images and underlying geodata.

Seeing such processes in "reality" will bring much better understand for
planners, authorities, population etc. than the best crafted 2D maps
ever will.

Cheers,
Bernd

Am 15.10.23 um 13:08 schrieb Martin Dobias via QGIS-Developer:

Hi Hannes


__

the two ridiculously expensive and high-end graphics cards mentioned
by Luke sound like complete overkill. Surely reading and preparing
the geodata for 3D display (from data providers, via storage, on the
CPU?) would be the bigger performance/usability issue of the 3D
views, right? I am sure that for reasonable reasons QGIS would choke
wy earlier than what those cards would be capable of. The
potential benefit of those cards for QGIS 3D definitely is not worth
paying *1200-2500€* extra.

I have not had a chance to try QGIS 3D with such high-end cards yet, but
you're right, users would be probably hitting performance issues
elsewhere when working with large amounts of data (but this also depends
on data types, formats, styling etc.)

Martin/Jean, is there any change that you could provide a more
detailed specification of the hardware and software requirements for
QGIS 3D? It comes up again and again and I've just been searching
again without success. I step up to add it to the QGIS documentation
in early November.

Okay, great, let me try... there are very few firm requirements for QGIS
3D, so it's hard to answer some of the questions exactly.

Esri provides for example infos on the required OpenGL version and
extensions on

https://pro.arcgis.com/en/pro-app/latest/get-started/arcgis-pro-system-requirements.htm
 


E.g.: What is the minimum amount of GPU RAM necessary? How does it
scale with more complex 3D scenes and what happens if there is not
enough RAM?

There's no strict minimum really, but I would say 1 GB GPU memory should
be enough for many use cases. When dealing with large amounts of 3D data
- e.g. point clouds or tiled scenes (3D tiles), it won't hurt to have
more memory, although with default settings QGIS probably would not go
over 2 GB GPU memory usage. All layers use tiling, so with increased
distance of 3D data from camera, there's less detail displayed, which
limits GPU memory usage and GPU processing power needed.

Each map layer gets up 500 MB GPU memory, but only few that are memory
intense (like point clouds or tiled scene) would normally use all of it.
When a map layer gets to the limit, it will unload data (that are
currently not being displayed) from GPU memory to get under the 500 MB
limit. In the QGIS release 3.34 it will be possible to configure the
per-layer limit (and QGIS 3D views will show a warning if the limit has
been reached and none of the tiles can be unloaded).

Does it get slow (maybe with a message) or does it crash?

Any slowness should be caused by displaying too many triangles/points in
the 3D view (or possibly there could be something in QGIS code that runs
on CPU that is slow and affecting 3D performance for example when the 3D
scene is getting updated as the camera moves, scheduling loads of tiles).

To be honest I don't really know what happens if there's not enough GPU
memory - in theory there could be crashes, or the scene would be just
missing some data - or maybe something else, like freeze. It is worth
trying - it may depend on the operating system and the graphical drivers
as well.

Which renderer does it use on which platforms (I guess always
OpenGL?). Which OpenGL version is needed?

Yes it is always using OpenGL. Our 3D window requests OpenGL 4.3 core
profile. Shaders of materials that we use only need OpenGL 3.2 or 3.3.

I am not 100% sure how things are on Windows and macOS. Apparently,
Windows by default only provides very 

Re: [QGIS-Developer] QGIS 3D and Graphics Card Requirements

[Martin Dobias via QGIS-Developer]

Hi Hannes


the two ridiculously expensive and high-end graphics cards mentioned by
> Luke sound like complete overkill. Surely reading and preparing the geodata
> for 3D display (from data providers, via storage, on the CPU?) would be the
> bigger performance/usability issue of the 3D views, right? I am sure that
> for reasonable reasons QGIS would choke wy earlier than what those
> cards would be capable of. The potential benefit of those cards for QGIS 3D
> definitely is not worth paying *1200-2500€* extra.
>
I have not had a chance to try QGIS 3D with such high-end cards yet, but
you're right, users would be probably hitting performance issues elsewhere
when working with large amounts of data (but this also depends on data
types, formats, styling etc.)


> Martin/Jean, is there any change that you could provide a more detailed
> specification of the hardware and software requirements for QGIS 3D? It
> comes up again and again and I've just been searching again without
> success. I step up to add it to the QGIS documentation in early November.
>
Okay, great, let me try... there are very few firm requirements for QGIS
3D, so it's hard to answer some of the questions exactly.


> Esri provides for example infos on the required OpenGL version and
> extensions on
> https://pro.arcgis.com/en/pro-app/latest/get-started/arcgis-pro-system-requirements.htm
>
> E.g.: What is the minimum amount of GPU RAM necessary? How does it scale
> with more complex 3D scenes and what happens if there is not enough RAM?
>
There's no strict minimum really, but I would say 1 GB GPU memory should be
enough for many use cases. When dealing with large amounts of 3D data -
e.g. point clouds or tiled scenes (3D tiles), it won't hurt to have more
memory, although with default settings QGIS probably would not go over 2 GB
GPU memory usage. All layers use tiling, so with increased distance of 3D
data from camera, there's less detail displayed, which limits GPU memory
usage and GPU processing power needed.

Each map layer gets up 500 MB GPU memory, but only few that are memory
intense (like point clouds or tiled scene) would normally use all of it.
When a map layer gets to the limit, it will unload data (that are currently
not being displayed) from GPU memory to get under the 500 MB limit. In the
QGIS release 3.34 it will be possible to configure the per-layer limit (and
QGIS 3D views will show a warning if the limit has been reached and none of
the tiles can be unloaded).

Does it get slow (maybe with a message) or does it crash?
>
Any slowness should be caused by displaying too many triangles/points in
the 3D view (or possibly there could be something in QGIS code that runs on
CPU that is slow and affecting 3D performance for example when the 3D scene
is getting updated as the camera moves, scheduling loads of tiles).

To be honest I don't really know what happens if there's not enough GPU
memory - in theory there could be crashes, or the scene would be just
missing some data - or maybe something else, like freeze. It is worth
trying - it may depend on the operating system and the graphical drivers as
well.

Which renderer does it use on which platforms (I guess always OpenGL?).
> Which OpenGL version is needed?
>
Yes it is always using OpenGL. Our 3D window requests OpenGL 4.3 core
profile. Shaders of materials that we use only need OpenGL 3.2 or 3.3.

I am not 100% sure how things are on Windows and macOS. Apparently, Windows
by default only provides very old OpenGL 1.1, and users need to install
dedicated graphics drivers to get more recent OpenGL. But Qt also comes
with ANGLE library (that translates OpenGL calls to DirectX) which can be
used as a fallback option, and there's also software rasterizer as a last
resort. There's even QT_OPENGL env variable to pick an option explicitly
[1]. I think QGIS 3D will not work with ANGLE though, because it uses
desktop OpenGL, not OpenGL ES which ANGLE is meant to support.

All this is related to Qt5 which has been very OpenGL-centric. In Qt6
things will be different again, because Qt departed from being
OpenGL-centric and embraced Direct3D, Metal and Vulkan, and introduced
their own abstraction on top of those APIs called RHI. (They also stopped
using ANGLE.) So in Qt6, Qt3D has two options - either use the new RHI
renderer (default) or use the existing OpenGL renderer. We use the latter,
because we would need to migrate our materials/shaders to be RHI
compatible, and also stop using some features that RHI does not support,
like geometry shaders. Given that QGIS does not support Qt6 officially yet,
this is not something to worry about too much for now, only something to be
aware of for the future.

Which extensions are needed?
>
I am not aware of any OpenGL extensions that we would need in QGIS 3D (I
may be wrong though).

Could missing extensions get logged prominently to the user to avoid the
> "my 3D canvas is white/blank" issue (I guess that is the reason) that often
> comes up?
>