Debounced scale computation to reduce GetLegendGraphic requests

[vladyslav-tk]

Added a debounce for scale computation when the resolution changes to avoid making many GetLegendGraphic requests.

See JIRA issue: GSGEOC-452.
Examples
Storybook
API help
API documentation

[sbrunner]

Why not use https://github.com/camptocamp/ngeo/blob/master/src/misc/debounce.js?

[vladyslav-tk]

Why not use https://github.com/camptocamp/ngeo/blob/master/src/misc/debounce.js?

thanks, updated

[sbrunner]

Can be the default value be undefined => no debounce to have the same comportment as for gmfWMSSourceOptions.debounceDelay :-)

[arnaud-morvan]

IMHO, undefined is a good default value for a first release, try it on prod in real conditions, and then 500ms or 1s, maybe more, could be a good default value in a second pass (to be confirmed). This would avoid requesting legends when user takes time when using wheel to zoom, without reducing a lot the user experience in regard to legend.

Not sure where we should define this intrusive default value, on ngeo (front, globally shared) or c2cgeoportal (customer project config) side.

[sbrunner]

@arnaud-morvan I put 200ms as default value in c2cgoportal https://github.com/camptocamp/c2cgeoportal/pull/13187/changes is it too small?

[arnaud-morvan]

IMHO a higher value is acceptable, updating the map is the priority, having the legend updated after 1s or 2s seems acceptable to me. As far as the map rendering may take 1s, the user may zoom another time after 1s. But this is really subjective in facts, and may depends on user behavior and map rendering time.

[arnaud-morvan]

I suppose the user expect the legend to update once he finished zooming on his area of interest.

[sbrunner]

@ochriste What do you think?

[arnaud-morvan]

As far as I understood :

The first legend URL computation is not debounced, so this PR only affect the zoom event.
And in case of zoom the user is looking at the map, not at the legend.

And the first legend loading is lazy :

ngeo/src/layertree/component.html.js

Line 70 in fb3bf08

loading="lazy"

=> The image is requested only when the image element is visible (when the parent legend element is expanded).

All the GetLegendGraphic requests were put in the queue before the GetMap, even when legend element was not visible.

=> With loading=lazy, it has a side effect, when expanding the legend, the user see the legends loading, one by one, but it reduced the first map rendering in a project with a lot of layers from 2 min to 6 sec

=> User said : this is wonderfull

I would be interested to know if in case a legend has been visible, but become hidden ( we collapsed the parent group in layer tree ), but we change the URL, will we generate a GetLegendGraphic request ? Or will the loading=lazy attribute apply ?

=> Should we supend requests when image element is not visible and zoom change ?

Side note

As it happens:

• The frustrated user eventually accepted the situation: the project contained numerous layers, which slowed down loading times.
• The developer noted that the file took two minutes to load—making work impossible and turnaround times excessive—so he spent ten minutes optimizing it.
• Now, loading takes just six seconds for everyone, on a daily basis.

Second side note

95% of the time legend does not depends on the scale

My conclusion

2 sec is a good default value, if user complains we may reduce it

[sbrunner]

@arnaud-morvan I will wait the feedback of @ochriste before doing any change :-)

[arnaud-morvan]

@ochriste is on vacation, but pretty sure he will follow me if you do, put 2 sec please and we will see if somebody complains, actually people complains about map rendering. Or I miss something ?

honestly who wants to see the legend updated regarding the scale after 200ms ?

[ochriste]

@arnaud-morvan if a legend is collapsed, no subsequent getlegendgraphic request are done,
you can test that in any project

[ochriste]

@sbrunner im ok with anything that improve the current situation, so go ahead.
on a side not, is it testable somewhere ?

[sbrunner]

=> camptocamp/c2cgeoportal#13227

[ochriste]

@ochriste is on vacation, but pretty sure he will follow me if you do, put 2 sec please and we will see if somebody complains, actually people complains about map rendering. Or I miss something ?

honestly who wants to see the legend updated regarding the scale after 200ms ?

@arnaud-morvan just for clarification:

the issue is that too many requests are sent to the server, and the mapserver services are getting saturated and fail to handle requests at a proper speed, which impact ALL rendering, including of course the map.
so simply by existing, the getlegendgraphic requests WILL cause issues, and WILL statistically impact also getmap requests.
So by delaying getlegendgraphic, we 1) make getmap requets handleded first and 2) reduce the amount of getlegendgraphic requets fired during zoom change event, greatly reducing load on the mapserver service, which then can properly handle requests and more specifically getmap requests

[arnaud-morvan]

@ochriste yes, when user is zooming he is also looking at the map, not at the legend, if the legend change depending on the scale, 2s seems perfectly acceptable to me, the map rendering should be done in priority.

It seems we have the same opinion on this.